Skip to content

feat(core): add pino support#1215

Closed
NathanFlurry wants to merge 1 commit into
mainfrom
09-12-feat_core_add_pino_support
Closed

feat(core): add pino support#1215
NathanFlurry wants to merge 1 commit into
mainfrom
09-12-feat_core_add_pino_support

Conversation

@NathanFlurry
Copy link
Copy Markdown
Member

No description provided.

Copy link
Copy Markdown
Member Author

NathanFlurry commented Sep 13, 2025


How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

  • merge queue - adds this PR to the back of the merge queue
  • hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

@claude
Copy link
Copy Markdown

claude Bot commented Sep 13, 2025

Claude finished @NathanFlurry's task —— View job


PR Review: Adding Pino Logging Support

I've completed my review of this significant logging system migration. Here's my comprehensive feedback:

Review Tasks:

  • Examine the core logging system changes in packages/rivetkit/src/common/log.ts
  • Review Pino integration and configuration
  • Check structured logging implementation across key modules
  • Analyze error handling and log levels
  • Look for performance implications
  • Check for security concerns (sensitive data logging)
  • Evaluate consistency of logging patterns
  • Review test coverage implications
  • Provide comprehensive feedback and recommendations

Positive Changes

  1. Well-structured Pino integration: The new logging system in packages/rivetkit/src/common/log.ts:30-125 provides a clean abstraction with proper configuration management
  2. Comprehensive configuration options: Support for custom loggers, log levels, and environment-based configuration
  3. Proper logger caching: Efficient caching mechanism for child loggers prevents unnecessary recreations
  4. Consistent structured logging: Good adoption of structured logging patterns across the codebase (e.g., packages/rivetkit/src/actor/instance.ts:317, 368)
  5. Performance-conscious design: Logger creation is lazy and cached, and pino-logfmt transport is used for efficient formatting

⚠️ Areas of Concern

Critical Issues

  1. Error Handling Missing Context: Several error logs lack sufficient context:

    // packages/rivetkit/src/registry/serve.ts:17
    logger().error("failed to import @hono/node-server...");

    Should include the actual error: logger().error({ msg: "...", error: stringifyError(err) })

  2. Inconsistent Error Logging Pattern: Some places use structured logging for errors while others don't:

    // Good: packages/rivetkit/src/actor/instance.ts:670-673
    logger().error({
      msg: "error in `_onStateChange`",
      error: stringifyError(error),
    });
    
    // Bad: packages/rivetkit/src/registry/serve.ts:17
    logger().error("failed to import @hono/node-server...");

Security Concerns

  1. Potential Log Injection: The packages/rivetkit/src/common/utils.ts:287 stringifyError function includes full stack traces when _RIVETKIT_ERROR_STACK=1. This could expose sensitive file paths or internal implementation details in production logs.

  2. Message Logging Controls: The code has debug logging for messages (packages/rivetkit/src/client/actor-conn.ts:353) that should ensure no sensitive data is logged.

Performance Issues

  1. Frequent Logger Calls: The pattern logger() is called repeatedly instead of caching the logger instance. While the internal caching helps, this could be optimized by storing the logger reference.

  2. Default Log Level: The default fallback is "info" instead of "warn" (packages/rivetkit/src/common/log.ts:48), which could generate more logs than necessary in production.

Code Quality Issues

  1. Missing Type Safety: Some logging calls use any types for error data (packages/rivetkit/src/manager/router.ts:923-924).

  2. Inconsistent Message Formatting: Some log messages use different capitalization and formatting styles.

📝 Recommendations

High Priority Fixes

  1. Fix Error Context Loss: Update all error logging to include the actual error object:

    // Instead of:
    logger().error("failed to import @hono/node-server...");
    
    // Use:
    logger().error({
      msg: "failed to import @hono/node-server",
      error: stringifyError(err)
    });
  2. Sanitize Stack Traces: Add production-safe error logging that doesn't expose sensitive paths:

    export function stringifyError(error: unknown, includeStack = false): string {
      // Add logic to sanitize or exclude stack traces in production
    }
  3. Standardize Log Levels: Review the default log level strategy - consider "warn" as default instead of "info".

Medium Priority Improvements

  1. Logger Caching Optimization: Consider storing logger instances in modules rather than calling logger() repeatedly.

  2. Add Structured Logging Guidelines: Document the expected structured logging patterns for consistency.

  3. Type Safety: Add proper typing for error objects in logging calls.

Test Coverage

  1. Missing Tests: I don't see specific tests for the new logging infrastructure. Consider adding:
    • Tests for logger configuration
    • Tests for structured logging output format
    • Tests for error sanitization

🎯 Overall Assessment

This is a solid foundation for a logging system migration, but needs refinement before production use. The core architecture is well-designed, but the implementation has several consistency and security issues that should be addressed.

Recommendation: Request changes to address the critical error handling and security concerns before merging.


@pkg-pr-new
Copy link
Copy Markdown

pkg-pr-new Bot commented Sep 13, 2025

More templates

@rivetkit/actor

pnpm add https://pkg.pr.new/rivet-gg/rivetkit/@rivetkit/actor@1215

@rivetkit/cloudflare-workers

pnpm add https://pkg.pr.new/rivet-gg/rivetkit/@rivetkit/cloudflare-workers@1215

@rivetkit/core

pnpm add https://pkg.pr.new/rivet-gg/rivetkit/@rivetkit/core@1215

@rivetkit/db

pnpm add https://pkg.pr.new/rivet-gg/rivetkit/@rivetkit/db@1215

@rivetkit/framework-base

pnpm add https://pkg.pr.new/rivet-gg/rivetkit/@rivetkit/framework-base@1215

@rivetkit/next-js

pnpm add https://pkg.pr.new/rivet-gg/rivetkit/@rivetkit/next-js@1215

@rivetkit/react

pnpm add https://pkg.pr.new/rivet-gg/rivetkit/@rivetkit/react@1215

rivetkit

pnpm add https://pkg.pr.new/rivet-gg/rivetkit@1215

@rivetkit/sql-loader

pnpm add https://pkg.pr.new/rivet-gg/rivetkit/@rivetkit/sql-loader@1215

commit: 26f78b8

@NathanFlurry NathanFlurry force-pushed the 09-12-feat_core_add_pino_support branch from 26f78b8 to d4050cc Compare September 13, 2025 22:24
@graphite-app
Copy link
Copy Markdown

graphite-app Bot commented Sep 13, 2025

Merge activity

  • Sep 13, 10:24 PM UTC: NathanFlurry added this pull request to the Graphite merge queue.
  • Sep 13, 10:25 PM UTC: CI is running for this pull request on a draft pull request (#1217) due to your merge queue CI optimization settings.
  • Sep 13, 10:26 PM UTC: Merged by the Graphite merge queue via draft PR: #1217.

@claude
Copy link
Copy Markdown

claude Bot commented Sep 13, 2025

Claude finished @NathanFlurry's task —— View job


Claude is reviewing the Pino logging PR

Review Tasks:

  • Read project guidelines in CLAUDE.md
  • Examine the core logging system changes in packages/rivetkit/src/common/log.ts
  • Review Pino integration and configuration
  • Check structured logging implementation across key modules
  • Analyze error handling and log levels
  • Look for performance implications
  • Check for security concerns (sensitive data logging)
  • Evaluate consistency of logging patterns
  • Review test coverage implications
  • Provide comprehensive feedback and recommendations

Positive Changes

  1. Well-structured Pino integration: The new logging system in packages/rivetkit/src/common/log.ts:30-125 provides a clean abstraction with proper configuration management
  2. Comprehensive configuration options: Support for custom loggers, log levels, and environment-based configuration
  3. Proper logger caching: Efficient caching mechanism for child loggers prevents unnecessary recreations
  4. Consistent structured logging: Good adoption of structured logging patterns across the codebase (e.g., packages/rivetkit/src/actor/instance.ts:317, 368)
  5. Performance-conscious design: Logger creation is lazy and cached, and pino-logfmt transport is used for efficient formatting

⚠️ Areas of Concern

Critical Issues

  1. Error Handling Missing Context: Several error logs lack sufficient context:

    // packages/rivetkit/src/registry/serve.ts:17
    logger().error("failed to import @hono/node-server...");

    Should include the actual error: logger().error({ msg: "...", error: stringifyError(err) })

  2. Inconsistent Error Logging Pattern: Some places use structured logging for errors while others don't:

    // Good: packages/rivetkit/src/actor/instance.ts:670-673
    logger().error({
      msg: "error in `_onStateChange`",
      error: stringifyError(error),
    });
    
    // Bad: packages/rivetkit/src/registry/serve.ts:17
    logger().error("failed to import @hono/node-server...");

Security Concerns

  1. Potential Log Injection: The packages/rivetkit/src/common/utils.ts:287 stringifyError function includes full stack traces when _RIVETKIT_ERROR_STACK=1. This could expose sensitive file paths or internal implementation details in production logs.

  2. Message Logging Controls: The code has debug logging for messages (packages/rivetkit/src/client/actor-conn.ts:353) that should ensure no sensitive data is logged.

Performance Issues

  1. Frequent Logger Calls: The pattern logger() is called repeatedly instead of caching the logger instance. While the internal caching helps, this could be optimized by storing the logger reference.

  2. Default Log Level: The default fallback is "info" instead of "warn" (packages/rivetkit/src/common/log.ts:48), which could generate more logs than necessary in production.

Code Quality Issues

  1. Missing Type Safety: Some logging calls use any types for error data (packages/rivetkit/src/manager/router.ts:923-924).

  2. Inconsistent Message Formatting: Some log messages use different capitalization and formatting styles.

📝 Recommendations

High Priority Fixes

  1. Fix Error Context Loss: Update all error logging to include the actual error object:

    // Instead of:
    logger().error("failed to import @hono/node-server...");
    
    // Use:
    logger().error({
      msg: "failed to import @hono/node-server",
      error: stringifyError(err)
    });
  2. Sanitize Stack Traces: Add production-safe error logging that doesn't expose sensitive paths:

    export function stringifyError(error: unknown, includeStack = false): string {
      // Add logic to sanitize or exclude stack traces in production
    }
  3. Standardize Log Levels: Review the default log level strategy - consider "warn" as default instead of "info".

Medium Priority Improvements

  1. Logger Caching Optimization: Consider storing logger instances in modules rather than calling logger() repeatedly.

  2. Add Structured Logging Guidelines: Document the expected structured logging patterns for consistency.

  3. Type Safety: Add proper typing for error objects in logging calls.

Test Coverage

  1. Missing Tests: I don't see specific tests for the new logging infrastructure. Consider adding:
    • Tests for logger configuration
    • Tests for structured logging output format
    • Tests for error sanitization

🎯 Overall Assessment

This is a solid foundation for a logging system migration, but needs refinement before production use. The core architecture is well-designed, but the implementation has several consistency and security issues that should be addressed.

Recommendation: Request changes to address the critical error handling and security concerns before merging.


graphite-app Bot pushed a commit that referenced this pull request Sep 13, 2025
@graphite-app graphite-app Bot closed this Sep 13, 2025
@graphite-app graphite-app Bot deleted the 09-12-feat_core_add_pino_support branch September 13, 2025 22:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant