fix: stats web styling + instrumentation#2454
Conversation
📝 WalkthroughWalkthroughThe pull request updates UI component styling across banner and toggle elements, refactors logging context strings for improved organization, and introduces a new instrumentation module that validates environment variables against a server schema when running in Node.js runtime, exiting on validation failure. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
apps/stats-web/src/instrumentation.ts (3)
8-8: Consider clarifying the env-loader import pattern.The destructuring pattern ignores the first import result, which suggests
@akashnetwork/env-loaderis imported solely for its side effects (e.g., loading.envfiles). While this works correctly, the intent could be clearer to future maintainers.🔎 Optional refactor for clarity
- const [, { serverEnvSchema }] = await Promise.all([import("@akashnetwork/env-loader"), import("./config/env-config.schema")]); + // Import env-loader for side effects (loads .env files) + await import("@akashnetwork/env-loader"); + const { serverEnvSchema } = await import("./config/env-config.schema");Or if parallel loading is important for performance:
- const [, { serverEnvSchema }] = await Promise.all([import("@akashnetwork/env-loader"), import("./config/env-config.schema")]); + const [, { serverEnvSchema }] = await Promise.all([ + import("@akashnetwork/env-loader"), // Imported for side effects + import("./config/env-config.schema") + ]);
12-12: Follow Pino conventions for error logging.The error logging format uses
{ message: "...", error }, but Pino's standard convention is to use theerrkey for error objects andmsg(or just pass a string as the second argument) for messages. Using the conventional format ensures proper error serialization and stack trace handling.🔎 Recommended fix to align with Pino conventions
- logger.error({ message: "Failed to validate server environment variables", error }); + logger.error({ err: error, msg: "Failed to validate server environment variables" });
1-3: Consider using createOtelLogger for enhanced observability.Based on learnings, backend services can benefit from using
createOtelLoggerfrom@akashnetwork/logging/otelto include OpenTelemetry trace context in logs. While this instrumentation file runs during startup rather than handling runtime requests, adding OTel context could still enhance observability for debugging initialization issues.Based on learnings: For backend services, prefer using createOtelLogger to include OpenTelemetry trace context in logs.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/stats-web/src/instrumentation.ts
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/general.mdc)
**/*.{ts,tsx,js}: Never use typeanyor cast to typeany. Always define the proper TypeScript types.
Never use deprecated methods from libraries.
Don't add unnecessary comments to the code.
Files:
apps/stats-web/src/instrumentation.ts
🧠 Learnings (1)
📚 Learning: 2025-11-12T09:03:40.132Z
Learnt from: stalniy
Repo: akash-network/console PR: 0
File: :0-0
Timestamp: 2025-11-12T09:03:40.132Z
Learning: For backend services (like the Indexer), prefer using createOtelLogger from "akashnetwork/logging/otel" to include OpenTelemetry trace context in logs.
Applied to files:
apps/stats-web/src/instrumentation.ts
⏰ 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). (2)
- GitHub Check: test-build
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (1)
apps/stats-web/src/instrumentation.ts (1)
1-3: NEXT_RUNTIME is reliably available at module load time.The
NEXT_RUNTIMEenvironment variable is set by Next.js during server initialization before theinstrumentation.tsmodule is imported. This is a standard Next.js pattern, as confirmed by the consistent implementation across bothapps/stats-webandapps/deploy-web. The logger will have the correct runtime value in its name.
2 participants
Summary by CodeRabbit
Style
Chores
✏️ Tip: You can customize this high-level summary in your review settings.