Conversation
- Removed Langfuse configuration from .env.example and added Lamina configuration. - Updated eslint.config.js to ignore specific TypeScript declaration files. - Refactored next.config.ts for better readability of serverExternalPackages. - Modified index.ts to integrate Laminar API key for observability. - Enhanced tsconfig.json to include additional type definitions and exclude unnecessary files.
Learn moreAll Green is an AI agent that automatically: ✅ Addresses code review comments ✅ Fixes failing CI checks ✅ Resolves merge conflicts |
Reviewer's GuideConfigures observability to use Laminar via OtelExporter, refactors Next.js serverExternalPackages for readability, and tightens TypeScript/ESLint configuration to better control which files are type-checked and linted while excluding problematic declaration files. Sequence diagram for Laminar-based observability via OtelExportersequenceDiagram
participant Client
participant NextApp
participant Mastra
participant Observability
participant OtelExporter
participant LaminarAPI
Client->>NextApp: HTTP request
NextApp->>Mastra: Handle request and operations
Mastra->>Observability: Create and record trace spans
Observability->>OtelExporter: Export spans with serviceName my-service
OtelExporter->>OtelExporter: Attach laminar apiKey from LMNR_PROJECT_API_KEY
OtelExporter->>OtelExporter: Add resourceAttributes deployment.environment=dev
OtelExporter->>LaminarAPI: Send trace data using laminar provider
LaminarAPI-->>OtelExporter: Acknowledge receipt
OtelExporter-->>Observability: Export result
Observability-->>Mastra: Trace export completed
Mastra-->>NextApp: Operation result
NextApp-->>Client: HTTP response
Class diagram for Mastra observability configuration with LaminarclassDiagram
class Mastra {
+Observability observability
+configureObservability(observability)
}
class Observability {
+string defaultEnabled
+string configs
+setConfig(key, value)
}
class OtelExporter {
+string serviceName
+string providerType
+string laminarApiKey
+string logger
+string deploymentEnvironment
+exportTraces(spans)
}
class LaminarProviderConfig {
+string apiKey
+string teamId
}
Mastra --> Observability : has
Observability --> OtelExporter : uses
OtelExporter --> LaminarProviderConfig : configures
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Caution Review failedThe pull request is closed. Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughReplaces Langfuse with Lamina config and Otel/TraceLoop exporter, expands serverExternalPackages and ESLint ignore entries, adjusts TypeScript include/exclude patterns, and introduces multiple chat UI, streaming, tooling, and network-data handling changes including grouped tool rendering and standardized data-tool-progress payloads. Changes
Sequence Diagram(s)mermaid Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: ASSERTIVE Plan: Pro 📒 Files selected for processing (12)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🤖 Hi @ssdeanx, I've received your request, and I'm working on it now! You can track my progress in the logs for more details. |
Summary of ChangesHello @ssdeanx, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request focuses on updating the project's configuration and improving its type-checking setup. It primarily involves switching the observability provider from Langfuse to Lamina, which necessitated changes in environment variable examples and the core observability integration. Additionally, the type-checking configuration has been refined to ensure better coverage and exclude problematic declaration files, contributing to a more robust development experience. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
🤖 I'm sorry @ssdeanx, but I was unable to process your request. Please see the logs for more details. |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
- In
src/mastra/index.ts, thedefault: { enabled: false }observability config is now commented out rather than removed or replaced; consider making the intended default behavior explicit (enabled vs disabled) via configuration instead of leaving commented code. - In
tsconfig.json,types/**/*.d.tsappears twice in theincludearray and the inline comment about excluding tests no longer matches the actual include list; it would be clearer to deduplicate the pattern and update or relocate the comment so it accurately reflects the current configuration. - The ESLint and TypeScript configs both ignore specific declaration files under
node_modules; if possible, prefer addressing these via parser/tsconfig options or local type shim declarations rather than hardcoding deepnode_modulespaths, which can be brittle to library updates.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In `src/mastra/index.ts`, the `default: { enabled: false }` observability config is now commented out rather than removed or replaced; consider making the intended default behavior explicit (enabled vs disabled) via configuration instead of leaving commented code.
- In `tsconfig.json`, `types/**/*.d.ts` appears twice in the `include` array and the inline comment about excluding tests no longer matches the actual include list; it would be clearer to deduplicate the pattern and update or relocate the comment so it accurately reflects the current configuration.
- The ESLint and TypeScript configs both ignore specific declaration files under `node_modules`; if possible, prefer addressing these via parser/tsconfig options or local type shim declarations rather than hardcoding deep `node_modules` paths, which can be brittle to library updates.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates configuration files and improves type checking by replacing Langfuse with Lamina for observability, cleaning up next.config.ts, and refining TypeScript configurations. My review focuses on the new observability setup and tsconfig.json changes. I've identified a few areas for improvement in src/mastra/index.ts to make the new Laminar configuration more robust by validating the API key and using environment variables for service name and environment. Additionally, there's a redundant entry in tsconfig.json that can be removed. Overall, these are good changes that improve the project's configuration.
src/mastra/index.ts
Outdated
| new OtelExporter({ | ||
| provider: { | ||
| laminar: { | ||
| apiKey: process.env.LMNR_PROJECT_API_KEY, |
There was a problem hiding this comment.
The LMNR_PROJECT_API_KEY environment variable is used directly. If it's not set, apiKey will be undefined, which could lead to runtime errors or silent failures in the observability setup. It's safer to validate that the environment variable is present before using it and fail fast if it's missing, or at least provide a default empty string ?? '' to avoid passing undefined.
| } | ||
| } | ||
| })] | ||
| serviceName: "my-service", |
There was a problem hiding this comment.
The serviceName is set to a generic value "my-service". It would be more informative to use a specific name for this service, for example, the application name from package.json (agentstack) or an environment variable. This helps in identifying the service in the observability platform.
| serviceName: "my-service", | |
| serviceName: process.env.OTEL_SERVICE_NAME ?? "agentstack", |
| logger: log, | ||
| resourceAttributes: { | ||
| // Optional OpenTelemetry Resource Attributes for the trace | ||
| ["deployment.environment"]: "dev", |
There was a problem hiding this comment.
The deployment.environment is hardcoded to "dev". This is not ideal for different environments like staging or production. It would be better to source this value from an environment variable, such as NODE_ENV.
| ["deployment.environment"]: "dev", | |
| ["deployment.environment"]: process.env.NODE_ENV ?? "dev", |
| "tests/**/*.tsx" | ||
| // Tests are excluded from the main typecheck run to avoid typechecking test-only imports | ||
| // that may pull in declaration files with unsupported syntax from node_modules. | ||
| "types/**/*.d.ts", |
There was a problem hiding this comment.
The path "types/**/*.d.ts" is included twice in the include array (the first inclusion is on line 54). While this doesn't cause an error, this entry is redundant and can be removed for clarity.
Greptile OverviewGreptile SummaryThis PR migrates the observability stack from Langfuse to Laminar and improves TypeScript type checking by excluding problematic declaration files.
Critical Issue: The Confidence Score: 2/5
Important Files ChangedFile Analysis
Sequence DiagramsequenceDiagram
participant Dev as Developer
participant Env as .env.example
participant TS as TypeScript Config
participant ESLint as ESLint Config
participant Next as Next.js Config
participant Mastra as Mastra Instance
participant Laminar as Laminar Service
Dev->>Env: Update environment variables
Note over Env: Remove LANGFUSE_* vars<br/>Add LMNR_PROJECT_API_KEY
Dev->>TS: Update tsconfig.json
Note over TS: Add utils/, styles/, types/ dirs<br/>Exclude problematic .d.ts files
Dev->>ESLint: Update eslint.config.js
Note over ESLint: Ignore node_modules/@crawlee/<br/>and @mdx-js declaration files
Dev->>Next: Refactor next.config.ts
Note over Next: Alphabetize serverExternalPackages
Dev->>Mastra: Update observability config
Note over Mastra: Remove LangfuseExporter import<br/>Add Laminar OtelExporter<br/>⚠️ Comment out default disabled flag
Mastra->>Mastra: Initialize with new config
alt LMNR_PROJECT_API_KEY is set
Mastra->>Laminar: Connect with API key
Laminar-->>Mastra: Connection established
else API key not set
Mastra-xLaminar: ⚠️ Observability enabled but unconfigured
Note over Mastra: Potential runtime error
end
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| logger: log, | ||
| observability: new Observability({ | ||
| default: { enabled: false }, | ||
| // default: { enabled: false }, |
There was a problem hiding this comment.
logic: Commenting out default: { enabled: false } will enable observability by default. If Laminar isn't configured, this could cause startup errors or send traces unexpectedly.
| // default: { enabled: false }, | |
| default: { enabled: false }, |
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/mastra/index.ts
Line: 187:187
Comment:
**logic:** Commenting out `default: { enabled: false }` will enable observability by default. If Laminar isn't configured, this could cause startup errors or send traces unexpectedly.
```suggestion
default: { enabled: false },
```
How can I resolve this? If you propose a fix, please make it concise.| @@ -58,8 +64,10 @@ | |||
| "hooks/**/*.tsx", | |||
| "pages/**/*.ts", | |||
| "pages/**/*.tsx", | |||
| "tests/**/*.ts", | |||
| "tests/**/*.tsx" | |||
| // Tests are excluded from the main typecheck run to avoid typechecking test-only imports | |||
| // that may pull in declaration files with unsupported syntax from node_modules. | |||
| "types/**/*.d.ts", | |||
There was a problem hiding this comment.
style: types/**/*.d.ts appears twice in the include array (lines 54 and 69)
| "types/**/*.d.ts", | |
| "utils/**/*.ts", | |
| "utils/**/*.tsx", | |
| "styles/**/*.ts", | |
| "styles/**/*.tsx", |
Prompt To Fix With AI
This is a comment left during a code review.
Path: tsconfig.json
Line: 54:69
Comment:
**style:** `types/**/*.d.ts` appears twice in the include array (lines 54 and 69)
```suggestion
"types/**/*.d.ts",
"utils/**/*.ts",
"utils/**/*.tsx",
"styles/**/*.ts",
"styles/**/*.tsx",
```
How can I resolve this? If you propose a fix, please make it concise.![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
.env.example(1 hunks)eslint.config.js(1 hunks)next.config.ts(1 hunks)src/mastra/index.ts(1 hunks)tsconfig.json(3 hunks)
🧰 Additional context used
📓 Path-based instructions (13)
tsconfig*.json
📄 CodeRabbit inference engine (AGENTS.md)
Configure TypeScript with separate tsconfig.json for app (ES2022) and tsconfig.cli.json for CLI builds (CommonJS)
Files:
tsconfig.json
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.github/instructions/next-js.instructions.md)
**/*.{js,jsx,ts,tsx}: Usenext/dynamicfor dynamic imports to load components only when needed, improving initial load time.
Usenext/imagecomponent for automatic image optimization, including lazy loading and responsive images.
Use React.memo to prevent unnecessary re-renders of components.
Use the<Link prefetch>tag to prefetch pages that are likely to be visited.
Use getServerSideProps, getStaticProps, or server components for fetching data on the server-side.
Use SWR or React Query for client-side data fetching and caching.
Use CSS Modules, Styled Components, or Tailwind CSS for component-level styling. Prefer Tailwind CSS for rapid development.
Use React Context, Zustand, Jotai, or Recoil for managing global state. Avoid Redux unless necessary.
Usereact-hook-formfor managing forms and validation.
Only fetch the data that is needed by the component to avoid over-fetching.
Avoid long-running synchronous operations in the main thread to prevent blocking.
Always usesetStateor hooks to update state instead of mutating state directly.
Include a complete dependency array inuseEffecthooks to prevent unexpected behavior.
Avoid writing server-side code in client components to prevent exposing secrets or causing unexpected behavior.
Usetry...catchblocks for handling errors in asynchronous operations.
Implement error boundary components usinggetDerivedStateFromErrororcomponentDidCatchlifecycle methods.
Sanitize user input to prevent Cross-Site Scripting (XSS) attacks. Be especially careful when rendering HTML directly from user input.
Store authentication tokens in HTTP-only cookies or local storage securely.
Implement role-based access control to restrict access to sensitive resources.
Clean up event listeners and timers inuseEffecthooks to avoid memory leaks.
Only update state when necessary to reduce the number of re-renders and improve performance.
Use immutable data structures and avoid mutating data directly to prevent unexpected...
Files:
next.config.tssrc/mastra/index.tseslint.config.js
**/next.config.{js,ts}
📄 CodeRabbit inference engine (.github/instructions/next-js.instructions.md)
**/next.config.{js,ts}: Integrate linting and formatting into the build process to ensure consistent code.
Analyze bundle size using tools likewebpack-bundle-analyzerto identify large dependencies.
Use tree shaking to remove unused code from bundles.
Files:
next.config.ts
**/*.{js,ts}
📄 CodeRabbit inference engine (.github/instructions/next-js.instructions.md)
Use parameterized queries or an ORM to prevent SQL injection attacks.
Files:
next.config.tssrc/mastra/index.tseslint.config.js
**/*.{ts,tsx,js,jsx,py,java,cs,rb,go,rs,cpp,c,h,hpp,swift,kotlin,php,scala,clj,groovy,lua,sh,bash}
📄 CodeRabbit inference engine (.github/instructions/self-explanatory-code-commenting.instructions.md)
**/*.{ts,tsx,js,jsx,py,java,cs,rb,go,rs,cpp,c,h,hpp,swift,kotlin,php,scala,clj,groovy,lua,sh,bash}: Write code that speaks for itself. Comment only when necessary to explain WHY, not WHAT. Avoid obvious comments that state what the code literally does.
Avoid redundant comments that simply repeat what the code is doing
Keep comments accurate and up-to-date with code changes. Remove or update outdated comments that no longer match the implementation.
Write comments for complex business logic that explain the WHY behind specific calculations or business rules
Document non-obvious algorithms with comments explaining the algorithm choice and its reasoning
Add comments explaining what regex patterns match, especially for complex patterns
Document API constraints, rate limits, gotchas, and external dependencies with explanatory comments
Avoid commenting out dead code. Use version control instead of maintaining commented code blocks.
Do not maintain code change history or modification logs as comments. Rely on git history and commit messages instead.
Avoid decorative divider comments (e.g., lines of equals signs or asterisks) for section separation
Ensure comments are placed appropriately above or adjacent to the code they describe
Write comments using proper grammar, spelling, and professional language
Prefer self-documenting code with clear variable/function names over adding comments to explain unclear code
Files:
next.config.tssrc/mastra/index.tseslint.config.js
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/instructions/self-explanatory-code-commenting.instructions.md)
**/*.{ts,tsx,js,jsx}: Document public APIs with TSDoc/JSDoc comments including parameter descriptions, return types, examples, and thrown exceptions
Add TSDoc comments to configuration constants and environment variables explaining their source, reasoning, or constraints
Use TSDoc annotation tags (TODO, FIXME, HACK, NOTE, WARNING, PERF, SECURITY, BUG, REFACTOR, DEPRECATED) to mark special comments
Include file headers with @fileoverview, @author, @copyright, and @license tags to document file purpose and ownership
Document function parameters with @param tags, return values with @returns tags, and exceptions with @throws tags in TSDoc comments
Use @see tags in TSDoc comments to reference related functions, methods, or documentation
Include @example tags in public API documentation with code examples showing typical usage
**/*.{ts,tsx,js,jsx}: Use Mastra mcp tools (#mastradocs,#mastraChanges,#mastraexamples,#mastraBlog) for Mastra framework development to stay updated with latest features and best practices
When working with Next.js projects, always utilize thenext-devtools-mcpserver for all Next.js related queries
Files:
next.config.tssrc/mastra/index.tseslint.config.js
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/instructions/self-explanatory-code-commenting.instructions.md)
**/*.{ts,tsx}: Document interface and type definitions with TSDoc comments explaining their purpose and usage context
Document interface properties with /** */ comments explaining each field's purpose and constraints
Document generic type parameters with @template tags explaining what each type parameter represents
Use type guards with comments explaining the runtime validation logic being performed
Document advanced/complex TypeScript types with explanatory comments about their purpose and use cases
Files:
next.config.tssrc/mastra/index.ts
**/*.{css,tsx,ts}
📄 CodeRabbit inference engine (AGENTS.md)
Use Tailwind CSS 4 with oklch color variables for styling
Files:
next.config.tssrc/mastra/index.ts
src/mastra/index.ts
📄 CodeRabbit inference engine (src/AGENTS.md)
Enforce registration pattern in
mastra/index.tsfor AI orchestration modules composition
Files:
src/mastra/index.ts
src/mastra/**/*
📄 CodeRabbit inference engine (src/AGENTS.md)
mastramodules can import fromutils, but must not import fromapporcli(excepttypes)
Files:
src/mastra/index.ts
**/.env*
📄 CodeRabbit inference engine (.github/instructions/next-js.instructions.md)
Use environment variables to store configuration values in the application.
Files:
.env.example
{.env*,**.github/workflows/**/*.{yml,yaml}}
📄 CodeRabbit inference engine (AGENTS.md)
Never commit API keys or secrets to the repo; use .env locally and secure env variables in CI/CD
Files:
.env.example
.env*
📄 CodeRabbit inference engine (AGENTS.md)
Environment configuration should include at minimum: SUPABASE/DATABASE_URL, GOOGLE_GENERATIVE_AI_API_KEY, and optional provider keys (OPENAI_API_KEY, ANTHROPIC_API_KEY, OPENROUTER_API_KEY)
Files:
.env.example
🧬 Code graph analysis (1)
src/mastra/index.ts (1)
src/mastra/config/logger.ts (1)
log(14-18)
🪛 dotenv-linter (4.0.0)
.env.example
[warning] 27-27: [QuoteCharacter] The value has quote characters (', ")
(QuoteCharacter)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: CodeQL analysis (javascript-typescript)
- GitHub Check: Agent
- GitHub Check: Sourcery review
- GitHub Check: Codacy Security Scan
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (4)
next.config.ts (1)
7-23: LGTM! Server external packages configuration is appropriate.The expanded
serverExternalPackageslist correctly identifies packages that should remain external to the Next.js server bundle:
- Mastra ecosystem packages (
@mastra/*,@mcpc-tech/*, etc.)- Server-only utilities (playwright-core, pdf-parse, csv-parse, re2)
- Packages requiring Node.js APIs (cheerio, jose, marked)
The wildcard patterns efficiently cover package scopes while keeping the configuration maintainable.
As per coding guidelines, consider analyzing the bundle size impact using
webpack-bundle-analyzerto verify that bundling exclusions are optimal.tsconfig.json (2)
53-58: LGTM! Type definition coverage expanded appropriately.The new include patterns broaden TypeScript's type-checking scope to cover:
- Mastra type definitions (
src/mastra/types/**/*.d.ts)- Project-wide type definitions (
types/**/*.d.ts)- Utility and style modules (
utils/**/*,styles/**/*)This aligns with the PR objective of improving type checking across the project.
85-87: Consistent exclusion of problematic node_modules declarations.Excluding specific declaration files from both ESLint (eslint.config.js lines 26-27) and TypeScript compilation ensures these files with syntax issues don't break the build pipeline. This approach is acceptable for addressing upstream package issues.
eslint.config.js (1)
26-27: Remove this comment—these ignores are necessary and justified.Both
eslint.config.jsandtsconfig.jsonexplicitly excludenode_modules/@crawlee/http/internals/http-crawler.d.tsandnode_modules/@mdx-js/loader/index.d.ctsbecause these specific declaration files cause parsing or type-checking issues. The blanketnode_modules/**ignore does not prevent these files from being processed. The explicit exclusions were added intentionally in a coordinated configuration update and are required for both ESLint and TypeScript to function correctly with these packages.
| # Lamina Configuration | ||
| LMNR_PROJECT_API_KEY='your_project_api_key_here' |
There was a problem hiding this comment.
Remove quote characters from environment variable placeholder.
The migration from Langfuse to Lamina configuration looks correct. However, environment variable values in .env files should not include quote characters - they become part of the actual value when parsed.
Based on coding guidelines, environment variables should be stored without quotes. Apply this diff:
# Lamina Configuration
-LMNR_PROJECT_API_KEY='your_project_api_key_here'
+LMNR_PROJECT_API_KEY=your_project_api_key_hereThis aligns with the pattern used by other variables in this file (e.g., lines 4-5, 24).
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Lamina Configuration | |
| LMNR_PROJECT_API_KEY='your_project_api_key_here' | |
| # Lamina Configuration | |
| LMNR_PROJECT_API_KEY=your_project_api_key_here |
🧰 Tools
🪛 dotenv-linter (4.0.0)
[warning] 27-27: [QuoteCharacter] The value has quote characters (', ")
(QuoteCharacter)
🤖 Prompt for AI Agents
In .env.example around lines 26 to 27, the LMNR_PROJECT_API_KEY placeholder is
wrapped in single quotes which will become part of the value when parsed; remove
the quote characters so the line reads
LMNR_PROJECT_API_KEY=your_project_api_key_here to match other entries and avoid
embedding quotes in the environment value.
| serviceName: "my-service", | ||
| exporters: [ | ||
| new OtelExporter({ | ||
| provider: { | ||
| laminar: { | ||
| apiKey: process.env.LMNR_PROJECT_API_KEY, | ||
| // teamId: process.env.LAMINAR_TEAM_ID, // Optional, for backwards compatibility | ||
| }, | ||
| }, | ||
| logger: log, | ||
| resourceAttributes: { | ||
| // Optional OpenTelemetry Resource Attributes for the trace | ||
| ["deployment.environment"]: "dev", | ||
| }, | ||
| }), | ||
| ], |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the file and the specific lines mentioned
cat -n src/mastra/index.ts | head -220 | tail -50Repository: ssdeanx/AgentStack
Length of output: 2200
🏁 Script executed:
# Check if .env.example exists and contains the referenced variable
find . -name ".env*" -type f | head -10Repository: ssdeanx/AgentStack
Length of output: 76
🏁 Script executed:
# Search for service name patterns and Laminar references
rg "serviceName" src/ -A2 -B2 --type ts --type jsRepository: ssdeanx/AgentStack
Length of output: 564
🏁 Script executed:
# Check for Laminar/LMNR references in the codebase
rg -i "lmnr|laminar" src/ --type ts --type js -C2Repository: ssdeanx/AgentStack
Length of output: 464
🏁 Script executed:
# Check .env.example content
cat -n .env.example | head -50Repository: ssdeanx/AgentStack
Length of output: 2033
🏁 Script executed:
# Search for project name or app name patterns
rg "mastra-app|AgentStack" . -t json -t ts -t js --type-add json:match .json -C1Repository: ssdeanx/AgentStack
Length of output: 17942
🏁 Script executed:
# Check package.json for project name
cat package.json | grep -A5 -B5 '"name"'Repository: ssdeanx/AgentStack
Length of output: 374
🏁 Script executed:
# Search for other service configurations or naming patterns
rg "service" src/mastra/ -i --type ts -C1 | head -40Repository: ssdeanx/AgentStack
Length of output: 2906
Replace placeholder service name with a descriptive identifier.
The Laminar OTEL exporter configuration is correctly structured with proper API key sourcing from LMNR_PROJECT_API_KEY and logger integration. However, the service name "my-service" (line 190) is a placeholder and should be replaced with a descriptive identifier that reflects your application. Consider aligning with your project naming conventions (e.g., "agentstack" matching your package.json name, or "mastra-app" as a service-specific identifier).
🤖 Prompt for AI Agents
In src/mastra/index.ts around lines 190 to 205, the exporter currently uses the
placeholder serviceName "my-service"; replace this with a descriptive identifier
that matches your project naming (for example the package.json "name" value like
"agentstack" or a service-specific value like "mastra-app"), or wire it to an
environment variable (e.g., process.env.SERVICE_NAME with a sensible fallback)
so the OTEL traces carry a meaningful service name consistent with your
deployment and naming conventions.
| // Tests are excluded from the main typecheck run to avoid typechecking test-only imports | ||
| // that may pull in declaration files with unsupported syntax from node_modules. | ||
| "types/**/*.d.ts", |
There was a problem hiding this comment.
Remove duplicate include entry and clarify comment.
Line 69 duplicates the types/**/*.d.ts pattern already included on line 54. Additionally, the comment mentions excluding tests from typechecking, but the entry below is an include pattern (not an exclude), and no test-specific patterns appear in the exclude section.
Apply this diff to remove the duplicate:
- // Tests are excluded from the main typecheck run to avoid typechecking test-only imports
- // that may pull in declaration files with unsupported syntax from node_modules.
- "types/**/*.d.ts",
-If test files need to be excluded, add patterns like **/*.test.ts, **/*.spec.ts to the exclude array instead.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // Tests are excluded from the main typecheck run to avoid typechecking test-only imports | |
| // that may pull in declaration files with unsupported syntax from node_modules. | |
| "types/**/*.d.ts", |
🤖 Prompt for AI Agents
In tsconfig.json around lines 67 to 69, remove the duplicate "types/**/*.d.ts"
include entry on line 69 and update the surrounding comment to reflect what the
entry does (or move the comment to the include block if it refers to types). If
the intent was to exclude tests from typechecking instead, add test glob
patterns such as "**/*.test.ts" and "**/*.spec.ts" to the "exclude" array rather
than leaving an inaccurate comment next to an include entry.
There was a problem hiding this comment.
Pull request overview
This PR migrates the observability provider from Langfuse to Laminar and improves TypeScript type checking by excluding problematic declaration files. The changes enhance configuration clarity by reformatting serverExternalPackages and adding explicit type inclusion paths in tsconfig.json.
Key Changes:
- Migration from Langfuse to Laminar for observability tracking with updated environment variables and configuration
- Improved type checking by excluding specific problematic TypeScript declaration files from both ESLint and TypeScript compilation
- Enhanced code readability by alphabetically sorting serverExternalPackages in next.config.ts
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| .env.example | Replaced Langfuse environment variables (LANGFUSE_SECRET_KEY, LANGFUSE_PUBLIC_KEY, LANGFUSE_BASE_URL) with Laminar configuration (LMNR_PROJECT_API_KEY) |
| eslint.config.js | Added exclusions for two problematic node_modules declaration files (@crawlee/http and @mdx-js/loader) to prevent linting errors |
| next.config.ts | Refactored serverExternalPackages from single-line to multi-line alphabetically sorted array for better readability |
| src/mastra/index.ts | Replaced Langfuse exporter with Laminar's OtelExporter, updated service configuration, and removed Langfuse import |
| tsconfig.json | Added explicit includes for types, utils, and styles directories; excluded problematic declaration files; added comment about test exclusion |
src/mastra/index.ts
Outdated
| new OtelExporter({ | ||
| provider: { | ||
| laminar: { | ||
| apiKey: process.env.LMNR_PROJECT_API_KEY, |
There was a problem hiding this comment.
Missing error handling for undefined API key. If LMNR_PROJECT_API_KEY is not set in the environment, this will pass undefined to the Laminar provider, which could cause runtime errors. Consider adding validation to ensure the API key is defined, or provide a fallback behavior with appropriate logging.
| apiKey: process.env.LMNR_PROJECT_API_KEY, | |
| apiKey: laminarApiKey, |
| logger: log, | ||
| resourceAttributes: { | ||
| // Optional OpenTelemetry Resource Attributes for the trace | ||
| ["deployment.environment"]: "dev", |
There was a problem hiding this comment.
Environment value is hardcoded as "dev". Consider using an environment variable like process.env.NODE_ENV or process.env.DEPLOYMENT_ENV to allow this to be configured for different deployment environments (development, staging, production).
| ["deployment.environment"]: "dev", | |
| ["deployment.environment"]: process.env.DEPLOYMENT_ENV || process.env.NODE_ENV || "development", |
| LANGFUSE_SECRET_KEY="sk-lf-your_secret_key_here" | ||
| LANGFUSE_PUBLIC_KEY="pk-lf-your_public_key_here" | ||
| LANGFUSE_BASE_URL="https://cloud.langfuse.com" | ||
| # Lamina Configuration |
There was a problem hiding this comment.
Typo in comment: "Lamina" should be "Laminar". The correct product name is "Laminar", not "Lamina".
| # Lamina Configuration | |
| # Laminar Configuration |
| logger: log, | ||
| observability: new Observability({ | ||
| default: { enabled: false }, | ||
| // default: { enabled: false }, |
There was a problem hiding this comment.
The commented-out line "default: { enabled: false }" should either be removed entirely or uncommented if it's needed. Leaving it commented creates ambiguity about the intended default observability behavior. Consider removing it if Laminar observability should be active by default, or uncomment it if observability should be opt-in.
| // default: { enabled: false }, |
| } | ||
| } | ||
| })] | ||
| serviceName: "my-service", |
There was a problem hiding this comment.
The service name "my-service" is a placeholder value that should be replaced with a meaningful name specific to this application. Consider using a descriptive name like "maestra-app" (as it was previously) or deriving it from an environment variable for better configurability.
| serviceName: "my-service", | |
| serviceName: process.env.MASTRA_SERVICE_NAME ?? "maestra-app", |
- Removed multiple empty <code-changes> tags to clean up the code. - Ensured consistency in the formatting of the changes section. - Prepared the code for future updates by maintaining a clear structure.
1 participant
Summary by Sourcery
Integrate Laminar-based observability and tighten TypeScript configuration and linting around problematic declaration files.
New Features:
Enhancements: