chore(rivetkit): log runner id with actor logs #3360

NathanFlurry · 2025-11-04T22:49:42Z

No description provided.

vercel · 2025-11-04T22:49:49Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
rivetkit-serverless	Ready	Preview	Comment	Nov 5, 2025 4:06am

3 Skipped Deployments

Project	Deployment	Preview	Updated (UTC)
rivet-cloud	Ignored		Nov 5, 2025 4:06am
rivet-inspector	Ignored	Preview	Nov 5, 2025 4:06am
rivet-site	Ignored	Preview	Nov 5, 2025 4:06am

NathanFlurry · 2025-11-04T22:50:01Z

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

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 · 2025-11-04T22:52:03Z

Code Review

Thanks for this PR! The change adds runner ID logging to actor logs, which will be valuable for debugging and tracing. Here's my feedback:

Positive Observations ✓

Clean Interface Design: The optional method getExtraActorLogParams? follows good TypeScript patterns by being optional, ensuring backward compatibility with other driver implementations
Proper Integration: The log params are correctly merged into both #log and #rLog loggers in the ActorInstance constructor
Safe Fallback: Using ?? "-" provides a safe default when runnerId is not yet available
Focused Change: The PR is well-scoped and addresses a single concern

Concerns & Suggestions

1. Potential Race Condition

Issue: The runnerId may not be set when getExtraActorLogParams() is first called during actor initialization.

Looking at the code flow:

The Runner is created and started in the constructor at line 279-280
Actors can be loaded via loadActor()
The runnerId is set asynchronously when the runner connects to the engine
getExtraActorLogParams() is called during ActorInstance initialization (line 331)

Recommendation: This appears intentional based on the fallback to "-", but consider:

Adding a comment explaining that runnerId may be "-" initially until the runner connects
Or, document in the JSDoc for getExtraActorLogParams that it should handle cases where IDs aren't yet available

2. Type Safety

Issue: The return type Record<string, string> requires all values to be strings, but TypeScript's type system doesn't enforce that this.#runner.runnerId is actually a string type.

Recommendation:

getExtraActorLogParams(): Record<string, string> {
    return { runnerId: String(this.#runner.runnerId ?? "-") };
}

This ensures type safety even if runnerId type changes in the future.

3. Missing Tests

Issue: No test coverage for the new functionality.

Recommendation: Consider adding a test in tests/driver-engine.test.ts that verifies:

The runnerId appears in actor logs after the runner connects
The fallback "-" value works correctly before connection

4. Documentation

Minor: The JSDoc comment is brief.

Recommendation: Expand the documentation:

/** 
 * Extra properties to add to logs for each actor.
 * Called during actor initialization to augment log context.
 * Values may be placeholders if not yet available (e.g., before runner connection).
 */
getExtraActorLogParams?(): Record<string, string>;

Questions

Is the "-" fallback the desired UX, or should we wait for the runner to connect before creating actors? (Current approach seems reasonable for non-blocking initialization)
Are there other driver implementations that might benefit from similar logging enhancement?

Verdict

The core implementation is solid and follows good patterns. The main concern is ensuring users understand that runnerId might initially be "-" in logs. Consider adding clarifying comments or documentation.

Approval Status: ✅ Approved with minor suggestions

Review generated by Claude Code

claude · 2025-11-05T01:58:01Z

Code Review

This PR adds runner ID logging to actor logs, which is valuable for debugging and tracing in distributed environments. Overall, the implementation is clean and follows good patterns. Here are my observations:

Positives ✓

Clean API design: The optional getExtraActorLogParams?() method in the ActorDriver interface follows the existing pattern of optional methods and provides good extensibility.
Proper use of optional chaining: The implementation correctly uses actorDriver.getExtraActorLogParams?.() with optional chaining and checks for the result before merging.
Consistent application: The extra log params are applied to both #log and #rLog loggers in the ActorInstance constructor (lines 331-345 in instance.ts).
Sensible default: Using "-" as a fallback when runnerId is undefined/null is reasonable for log consistency.

Suggestions for Improvement

Type safety concern: The return type Record<string, string> doesn't enforce that values must be strings. Consider what happens if this.#runner.runnerId is null (as opposed to undefined). The nullish coalescing operator ?? will handle both, but TypeScript might complain if runnerId can be null.

Recommendation: Verify the type of Runner.runnerId. If it can be null, the current code is fine. If it's typed as string | undefined, consider being explicit:
```
getExtraActorLogParams(): Record<string, string> {
    return { runnerId: this.#runner.runnerId ?? "-" };
}
```
Inconsistent implementation across drivers: The FileSystemActorDriver doesn't implement getExtraActorLogParams(). While optional methods don't require implementation, consider whether other drivers would benefit from similar context. For file-system drivers, you might want to log storage paths or other identifying information.

Recommendation: Document in the interface why this is optional and when drivers should/shouldn't implement it, or consider if FileSystemActorDriver could provide useful context too.
Timing consideration: The getExtraActorLogParams() is called during ActorInstance construction (line 331). At this point, has the runner necessarily established its ID? Looking at the code, #runner is initialized in the constructor (line 70), but runnerId might be set later via the runner protocol.

Recommendation: Verify that runnerId is available at ActorInstance construction time. If not, the fallback "-" will be used for all logs, defeating the purpose. Consider if the log params should be set/updated after runner initialization completes (after #runnerStarted resolves).
Test coverage: No tests are included for this functionality.

Recommendation: Add a test that verifies:
- Extra log params are correctly merged into actor logs
- The fallback "-" is used when runnerId is unavailable
- Other drivers that don't implement the method continue to work

Security & Performance

Security: No concerns. This only adds logging context.
Performance: Minimal impact - one method call and object merge per actor initialization.

Code Style

The code follows TypeScript conventions and matches the existing codebase style.

Final Assessment

This is a solid, straightforward change that adds valuable debugging information. The main risk is the timing issue - ensure runnerId is available when getExtraActorLogParams() is called. Otherwise, all actor logs will show runnerId: "-" instead of the actual ID.

Approve pending verification of the timing/initialization concern.

claude · 2025-11-05T01:59:06Z

Pull Request Review

This PR adds runner ID logging to actor instances by introducing a new optional method getExtraActorLogParams() to the ActorDriver interface. Overall, this is a clean and well-scoped change that improves observability. Here's my detailed feedback:

✅ Strengths

Good extensibility pattern: The optional method getExtraActorLogParams?() allows drivers to add custom log parameters without breaking existing implementations
Clean integration: The implementation properly merges extra log params into the existing log configuration at src/actor/instance.ts:331-332
Appropriate fallback: Uses ?? operator with "-" as fallback when runnerId is undefined, ensuring logs always have a value
Minimal scope: Only touches necessary files and doesn't introduce unnecessary complexity

🔍 Observations & Suggestions

1. Type Safety Consideration

The return type is Record<string, string> which assumes all log parameters are strings. This is appropriate for structured logging, but worth noting:

The runnerId is coerced to string with the fallback: this.#runner.runnerId ?? "-"
Consider documenting that values should be serializable primitives (strings/numbers)

2. Consistency Across Drivers

I noticed there are 3 ActorDriver implementations in the codebase:

EngineActorDriver (modified) ✅
FileSystemActorDriver ❓
CloudflareDurableObjectActorDriver ❓

Question: Should the other drivers also implement getExtraActorLogParams()?

File system driver could log the storage path or process ID
Cloudflare driver could log the Durable Object ID or isolate information

Since the method is optional, this is not blocking, but it might be worth considering for consistency.

3. Potential Race Condition

In engine-actor-driver.ts:602, the method accesses this.#runner.runnerId:

getExtraActorLogParams(): Record<string, string> {
    return { runnerId: this.#runner.runnerId ?? "-" };
}

This is called during actor initialization (line 331 of instance.ts). At that point:

The #runner is created at line 279-280 of actor-driver.ts
But runnerId might not be set until the runner starts (#runnerStarted.promise)

The fallback "-" handles this gracefully, but it means:

Early logs will show runnerId: "-"
Later logs (after runner starts) will still show runnerId: "-" because the logger is created once

Suggestion: If you want the actual runnerId in logs, you might need to:

Wait for #runnerStarted before creating the logger, OR
Document that early logs will use "-" as placeholder, OR
Create a dynamic log context that updates when runnerId becomes available

This may not be an issue if runnerId is always set synchronously, but worth clarifying.

4. Testing

No test changes were included. Consider:

Adding a test to verify getExtraActorLogParams() is called during actor initialization
Verifying the runnerId appears in log output
Testing the fallback behavior when runnerId is undefined

The driver-test-suite at rivetkit-typescript/packages/rivetkit/fixtures/driver-test-suite/ might be a good place for this.

📝 Minor Style Notes

Line 332 formatting: The conditional is concise, but could be more explicit for readability:

// Current
if (extraLogParams) Object.assign(logParams, extraLogParams);

// Alternative (more explicit)
if (extraLogParams !== undefined) {
    Object.assign(logParams, extraLogParams);
}

The current version is fine, just a style preference.

JSDoc comment: Consider adding a JSDoc comment to the interface method explaining:
- When this method is called (during actor initialization)
- That values should be serializable
- Example use case (like runnerId)

🎯 Summary

This is a solid, focused PR that adds valuable observability. The main considerations are:

Verify the timing of when runnerId is available vs when logs are created
Consider adding test coverage
Consider whether other drivers should implement this pattern

The implementation is clean and the optional method pattern is good design. Nice work! 🚀

Recommendation: ✅ Approve with minor suggestions for follow-up

claude · 2025-11-05T02:13:49Z

Code Review: PR #3360 - Log runner id with actor logs

Summary

This PR adds runner ID logging to actor instances by introducing an optional getExtraActorLogParams() method to the ActorDriver interface and implementing it in the EngineActorDriver.

Positive Aspects

✅ Clean interface design - Using an optional method (getExtraActorLogParams?()) is a good pattern that allows drivers to opt into providing extra log context without breaking existing implementations.

✅ Proper null handling - The fallback to "-" when runnerId is undefined/null is sensible and prevents log corruption.

✅ Minimal surface area - The change is focused and doesn't introduce unnecessary complexity.

Issues & Recommendations

1. Type Safety Concern - Return type could be more specific

File: rivetkit-typescript/packages/rivetkit/src/actor/driver.ts:55

The return type Record<string, string> allows any string values, but structured logging typically benefits from union types or more specific types. Consider:

// Current
getExtraActorLogParams?(): Record<string, string>;

// Suggested - more type-safe
getExtraActorLogParams?(): Record<string, string | number | boolean>;

This would allow numeric runner IDs or other typed metadata in the future.

2. Inconsistent Implementation - Missing implementation in Cloudflare Workers driver

File: rivetkit-typescript/packages/cloudflare-workers/src/actor-driver.ts

The CloudflareActorsActorDriver class also implements ActorDriver but doesn't provide an implementation of getExtraActorLogParams(). While optional, this creates inconsistent logging behavior across drivers.

Recommendation: Consider adding a similar implementation for Cloudflare Workers if runner/DO identification would be useful there:

getExtraActorLogParams(): Record<string, string> {
    // Could log Durable Object ID or other CF-specific context
    return { durableObjectId: this.#globalState./* ... */ };
}

3. Missing Test Coverage

There are no tests verifying:

That getExtraActorLogParams() is called during actor initialization
That the returned params are correctly merged into log context
That the fallback behavior ("-") works when runnerId is undefined

Recommendation: Add a test case in the driver test suite to verify this functionality.

4. Documentation Missing

The JSDoc comment for getExtraActorLogParams() is minimal:

/** Extra properties to add to logs for each actor. */

Recommendation: Expand documentation to clarify:

When this method is called (during actor initialization)
How the returned values are used (merged into structured log context)
Examples of useful metadata to include

Example:

/**
 * Provides extra properties to include in structured logs for all log statements
 * made by this actor instance.
 * 
 * Called once during actor initialization. The returned properties are merged
 * into the log context and will appear in all subsequent log entries for this actor.
 * 
 * @returns A record of string key-value pairs to include in log context.
 * @example
 * ```typescript
 * getExtraActorLogParams() {
 *   return { runnerId: this.#runner.runnerId ?? "-" };
 * }
 * ```
 */
getExtraActorLogParams?(): Record<string, string>;

5. Minor: Log Key Naming Convention

File: rivetkit-typescript/packages/rivetkit/src/drivers/engine/actor-driver.ts:602

The log key uses camelCase (runnerId), while checking the existing log params shows they also use camelCase (actorId, etc.), so this is consistent. However, consider whether this aligns with your observability platform's conventions (some prefer snake_case like runner_id for structured logging).

Security & Performance

✅ No security concerns identified
✅ Performance impact is negligible (single method call during initialization)

Overall Assessment

This is a solid, focused change that improves observability. The main areas for improvement are:

Adding test coverage
Improving documentation
Considering consistent implementation across all drivers
Minor type safety enhancement

Recommendation: Approve with suggestions for test coverage and documentation improvements.

claude · 2025-11-05T02:25:35Z

Code Review

Summary

This PR adds runner ID tracking to actor logs by introducing an optional getExtraActorLogParams() method to the ActorDriver interface. The implementation looks good overall with a clean extension point pattern. Here are my findings:

✅ Positive Aspects

Clean Design: The optional method pattern (getExtraActorLogParams?()) is a good choice that doesn't break existing implementations
Proper Fallback: The use of ?? operator with "-" fallback ensures logs always have a value even if runnerId is undefined
Consistent Logging: Adding the runner ID to both #log and #rLog loggers ensures complete trace coverage

🔍 Observations & Questions

Timing Consideration:
The getExtraActorLogParams() is called during ActorInstance.start() (line 331 in instance.ts), which happens in #runnerOnActorStart (line 411-418 in actor-driver.ts). At this point:

The Runner has been instantiated and started (line 279-280)
The onConnected callback should have fired, resolving #runnerStarted
The runnerId should be available

However, I notice that serverlessHandleStart explicitly waits for this.#runnerStarted.promise (line 590) before asserting the runner ID is set. This suggests there might be edge cases where actors start before the runner is fully connected.

Question: Can #runnerOnActorStart be called before onConnected fires? If so, the fallback "-" would be used, which might make debugging harder. Consider:

Adding a log warning when runnerId is undefined
Or ensuring actors can't start until runner is connected

📝 Minor Suggestions

Type Safety: Consider making the return type more explicit:

getExtraActorLogParams(): Record<string, string | number | boolean> {
  return { runnerId: this.#runner.runnerId ?? "-" };
}

This would allow for non-string metadata in the future.

Documentation: Add a JSDoc comment to getExtraActorLogParams in the interface explaining when it's called:

/**
 * Extra properties to add to logs for each actor.
 * Called during ActorInstance.start() before actor initialization.
 */
getExtraActorLogParams?(): Record<string, string>;

🎯 Test Coverage

No test changes are included. Consider adding:

A unit test verifying getExtraActorLogParams is called during actor initialization
A test ensuring logs include the runner ID when available
A test for the fallback behavior when runnerId is undefined

Security & Performance

✅ No security concerns identified
✅ No performance impact - this is a simple synchronous method call during initialization

Conclusion

This is a solid, minimal change that adds useful debugging information. The optional interface design is appropriate. My main question is about the timing guarantees around when runnerId is available versus when actors can start.

Recommendation: Approve with optional follow-up to clarify timing guarantees and add tests.

claude · 2025-11-05T02:26:43Z

Code Review: Add Runner ID to Actor Logs

Summary

This PR adds runner ID logging to actor instances by introducing an optional getExtraActorLogParams() method to the ActorDriver interface and implementing it in the EngineActorDriver.

Positive Observations

✅ Clean Interface Design: The use of an optional method (getExtraActorLogParams?()) is a good pattern that doesn't break existing driver implementations.

✅ Consistent Implementation: The extra log params are applied to both the main logger (#log) and runtime logger (#rLog) in ActorInstance.

✅ Fallback Handling: The code properly handles the case where runnerId might be undefined by providing a fallback value ("-").

Issues & Recommendations

1. Type Safety Concern (Minor)

Location: rivetkit-typescript/packages/rivetkit/src/actor/driver.ts:55

The return type Record<string, string> forces all values to be strings, but the implementation uses a nullish coalescing operator which suggests runnerId might not always be a string.

Current code:

getExtraActorLogParams?(): Record<string, string>;

In implementation:

return { runnerId: this.#runner.runnerId ?? "-" };

Recommendation: Consider using a more flexible type to allow for undefined or null values, or document that implementations must handle conversion:

getExtraActorLogParams?(): Record<string, string | number | undefined>;

Or keep the current type but add a JSDoc comment clarifying implementations must ensure string values.

2. Missing Implementations (Medium Priority)

Location: Other ActorDriver implementations

Two other drivers implement ActorDriver but don't implement getExtraActorLogParams():

FileSystemActorDriver (rivetkit-typescript/packages/rivetkit/src/drivers/file-system/actor.ts)
CloudflareActorsActorDriver (rivetkit-typescript/packages/cloudflare-workers/src/actor-driver.ts)

Impact: This is fine for optional methods, but these drivers might benefit from similar contextual logging. For example, the Cloudflare driver could log the Durable Object ID.

Recommendation: Consider adding implementations to other drivers in follow-up work, or document why only EngineActorDriver needs this.

3. Potential Timing Issue (Low Priority)

Location: rivetkit-typescript/packages/rivetkit/src/drivers/engine/actor-driver.ts:601-603

The getExtraActorLogParams() method is called during ActorInstance initialization, which happens during the actor's start() call. At this point, the runner might not be fully initialized.

Current code:

getExtraActorLogParams(): Record<string, string> {
    return { runnerId: this.#runner.runnerId ?? "-" };
}

Question: Is this.#runner.runnerId guaranteed to be set when loadActor() is called? Looking at the serverlessHandleStart implementation, there's an explicit check that the runner has started before accessing runnerId.

Recommendation: Verify that runnerId is available during actor initialization, or document that it's expected to be "-" initially and update later if needed.

4. Test Coverage (Medium Priority)

No tests were added to verify:

That getExtraActorLogParams() is called during actor initialization
That the runnerId appears in logs correctly
That the fallback value "-" is used when runnerId is undefined

Recommendation: Add a test case in the existing driver tests (e.g., tests/driver-engine.test.ts) to verify the logging behavior.

Security Considerations

✅ No security concerns identified. The runner ID is internal infrastructure metadata.

Performance Considerations

✅ Minimal performance impact. The method is called once during actor initialization, and the object creation is trivial.

Code Style

The code follows TypeScript conventions and is consistent with the existing codebase style.

Overall Assessment

This is a clean, focused change that adds useful debugging information. The main suggestions are:

Must fix: None
Should consider: Adding test coverage, verifying timing of runnerId availability
Nice to have: Implementing in other drivers, improving type safety documentation

Status: ✅ Approved - This can be merged as-is, with the recommendations addressed in follow-up work if needed.

claude · 2025-11-05T04:06:49Z

Code Review

Summary

This PR adds logging of runner IDs with actor logs by introducing an optional getExtraActorLogParams() method to the ActorDriver interface and implementing it in EngineActorDriver.

Code Quality ✅

Positives:

Clean, minimal implementation that follows TypeScript best practices
Uses optional chaining (?.()) appropriately to handle optional interface method
Consistent with existing logging patterns in the codebase
Good use of Record<string, string> for type safety

Potential Issues 🔍

1. Timing Consideration (Minor)
In actor-driver.ts:660, the method accesses this.#runner.runnerId:

getExtraActorLogParams(): Record<string, string> {
    return { runnerId: this.#runner.runnerId ?? "-" };
}

This method is called during ActorInstance construction (instance.ts:331), which happens before the runner may have started. The fallback to "-" handles this, but it means early logs might show runnerId: "-" instead of the actual ID.

Question: Is this intentional? Should we consider:

Documenting this behavior (that early logs may not have the runner ID)?
Or deferring log creation until after #runnerStarted.promise resolves?

2. Type Safety (Minor)
The return type Record<string, string> requires string values, but you're using this.#runner.runnerId ?? "-". If runnerId could be other types (number, etc.), this would need adjustment. Assuming it's string | undefined, this is correct.

Missing Implementation (Optional Driver Interface)

The FileSystemActorDriver (the other ActorDriver implementation) does not implement getExtraActorLogParams(). This is acceptable since it's an optional method, but:

Consideration: Should the file system driver also include any relevant context in logs? If not, this is fine as-is.

Test Coverage 📋

No tests were added. Given this is a logging enhancement, consider:

Adding a unit test that verifies getExtraActorLogParams() is called during actor instantiation
Verifying the runner ID appears in log output (if there's existing logging test infrastructure)

Performance ✅

Negligible impact - single object creation per actor instance initialization.

Security ✅

No security concerns. Logging runner IDs is appropriate for debugging and observability.

Documentation 📝

Consider adding JSDoc to explain:

When the method is called (during actor instance construction)
That the runner ID may not be available immediately (hence the fallback)

Example:

/**
 * Extra properties to add to logs for each actor.
 * Called during actor instance construction, so some values may not be available yet.
 */
getExtraActorLogParams?(): Record<string, string>;

Suggestions

Low Priority:

Consider if Record<string, unknown> would be more flexible than Record<string, string> for future extensibility
Add JSDoc documentation to the interface method
Consider adding a test to verify this functionality

Conclusion ✅

This is a clean, focused PR that improves observability. The implementation is solid with only minor considerations around timing and documentation. Approved with minor suggestions for enhancement.

🤖 Generated by Claude Code

claude · 2025-11-05T04:10:37Z

Code Review

This PR adds runner ID logging to actor logs by introducing an optional getExtraActorLogParams method to the ActorDriver interface. Overall, this is a clean and useful enhancement for debugging and observability.

✅ Strengths

Clean Design: The optional method approach (getExtraActorLogParams?()) is good - it doesn't break existing driver implementations.
Proper Integration: The extra log params are correctly merged into both logger instances (this.#log and this.#rLog) in ActorInstance.
Minimal Footprint: Small, focused change that adds value without over-engineering.

💡 Suggestions

1. Type Safety Improvement

Consider using a more specific return type to ensure consistency:

// Instead of Record<string, string>
getExtraActorLogParams?(): Record<string, unknown>;

This allows logging non-string values (numbers, booleans) which structured logging systems like Pino handle well.

2. Null Safety in Implementation

In actor-driver.ts:660, the fallback to "-" is reasonable, but consider:

getExtraActorLogParams(): Record<string, string> {
    // Only include runnerId if it exists
    return this.#runner.runnerId ? { runnerId: this.#runner.runnerId } : {};
}

This avoids logging runnerId: "-" which could be confusing when filtering logs.

3. Documentation

Add JSDoc to explain when/why extra params would be used:

/**
 * Extra properties to add to logs for each actor.
 * Useful for adding driver-specific identifiers (e.g., runner IDs, container IDs)
 * that help correlate actor logs with infrastructure logs.
 */
getExtraActorLogParams?(): Record<string, string>;

4. Other Drivers

Consider whether FileSystemActorDriver or CloudflareDurableObjectActorDriver could benefit from similar metadata:

File system: could log storage path or process ID
Cloudflare: could log Durable Object ID

Not necessary for this PR, but worth considering for consistency.

🔍 Questions

When is runnerId null? Understanding the lifecycle would help validate the fallback strategy.
Test Coverage: Are there existing tests that verify log output structure? This change affects all actor logs.

✅ No Issues Found

✅ Security: No concerns
✅ Performance: Negligible impact (one optional method call per actor instance)
✅ Error Handling: Proper null coalescing
✅ Code Style: Follows TypeScript conventions

Summary

Approve with minor suggestions. The core implementation is solid. Consider the type safety and null handling improvements for better maintainability.

Generated by Claude Code

graphite-app · 2025-11-05T05:07:39Z

Merge activity

Nov 5, 5:07 AM UTC: NathanFlurry added this pull request to the Graphite merge queue.
Nov 5, 5:08 AM UTC: CI is running for this pull request on a draft pull request (#3371) due to your merge queue CI optimization settings.
Nov 5, 5:11 AM UTC: Merged by the Graphite merge queue via draft PR: #3371.

NathanFlurry requested a review from MasterPtato November 4, 2025 22:49

This was referenced Nov 4, 2025

fix(guard): fix url decoding actor id + token #3357

Closed

chore(scripts): add endian converter script #3359

Closed

chore(rivetkit): log close code when client ws closes #3361

Closed

chore(rivetkit): add runner sse ping interval #3362

Closed

vercel bot deployed to Preview – rivetkit-serverless November 4, 2025 22:51 View deployment

MasterPtato approved these changes Nov 4, 2025

View reviewed changes

This was referenced Nov 5, 2025

chore(runner): improve runner connection logs #3365

Closed

fix(rivetkit): fix duplicate runner key in serverless #3366

Closed

NathanFlurry force-pushed the 11-04-chore_rivetkit_log_runner_id_with_actor_logs branch from 4b3360a to b33ce24 Compare November 5, 2025 01:54

NathanFlurry force-pushed the 11-04-chore_scripts_add_endian_converter_script branch from 6f6affa to 7e5b57a Compare November 5, 2025 01:54

This was referenced Nov 5, 2025

chore: misc bug fixes, add logs for outbound req #3332

Closed

fix: fix all dashboards #3358

Closed

feat(pb): add reschedule_ts to actors #3363

Closed

chore: change log levels #3333

Closed

vercel bot deployed to Preview – rivetkit-serverless November 5, 2025 01:56 View deployment

NathanFlurry force-pushed the 11-04-chore_scripts_add_endian_converter_script branch from 7e5b57a to 60e4821 Compare November 5, 2025 02:07

NathanFlurry force-pushed the 11-04-chore_rivetkit_log_runner_id_with_actor_logs branch from b33ce24 to 2b8185b Compare November 5, 2025 02:07

vercel bot deployed to Preview – rivetkit-serverless November 5, 2025 02:08 View deployment

NathanFlurry force-pushed the 11-04-chore_rivetkit_log_runner_id_with_actor_logs branch from 2b8185b to 78f7198 Compare November 5, 2025 02:18

NathanFlurry force-pushed the 11-04-chore_scripts_add_endian_converter_script branch from 60e4821 to 2cd2955 Compare November 5, 2025 02:18

vercel bot deployed to Preview – rivetkit-serverless November 5, 2025 02:19 View deployment

graphite-app bot force-pushed the 11-04-chore_scripts_add_endian_converter_script branch from 2cd2955 to c74dcd8 Compare November 5, 2025 02:33

graphite-app bot force-pushed the 11-04-chore_rivetkit_log_runner_id_with_actor_logs branch from 78f7198 to 95ffd87 Compare November 5, 2025 02:34

vercel bot deployed to Preview – rivetkit-serverless November 5, 2025 02:36 View deployment

chore(rivetkit): log runner id with actor logs

b462d64

NathanFlurry force-pushed the 11-04-chore_rivetkit_log_runner_id_with_actor_logs branch from 95ffd87 to b462d64 Compare November 5, 2025 04:04

NathanFlurry force-pushed the 11-04-chore_scripts_add_endian_converter_script branch from c74dcd8 to a904843 Compare November 5, 2025 04:04

NathanFlurry mentioned this pull request Nov 5, 2025

fix(next-js): auto shut down runners when source code updates #3369

Merged

vercel bot deployed to Preview – rivetkit-serverless November 5, 2025 04:06 View deployment

NathanFlurry mentioned this pull request Nov 5, 2025

chore(pegboard): allow configuring reschedule_backoff_max_exponent #3370

Merged

graphite-app bot pushed a commit that referenced this pull request Nov 5, 2025

chore(rivetkit): log runner id with actor logs (#3360)

0b3104e

graphite-app bot closed this Nov 5, 2025

graphite-app bot deleted the 11-04-chore_rivetkit_log_runner_id_with_actor_logs branch November 5, 2025 05:11

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

chore(rivetkit): log runner id with actor logs #3360

chore(rivetkit): log runner id with actor logs #3360

Uh oh!

NathanFlurry commented Nov 4, 2025

Uh oh!

vercel bot commented Nov 4, 2025 •

edited

Loading

Uh oh!

NathanFlurry commented Nov 4, 2025 •

edited

Loading

Uh oh!

claude bot commented Nov 4, 2025

Uh oh!

claude bot commented Nov 5, 2025

Uh oh!

claude bot commented Nov 5, 2025

Uh oh!

claude bot commented Nov 5, 2025

Uh oh!

claude bot commented Nov 5, 2025

Uh oh!

claude bot commented Nov 5, 2025

Uh oh!

claude bot commented Nov 5, 2025

Uh oh!

claude bot commented Nov 5, 2025

Uh oh!

graphite-app bot commented Nov 5, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

chore(rivetkit): log runner id with actor logs #3360

chore(rivetkit): log runner id with actor logs #3360

Uh oh!

Conversation

NathanFlurry commented Nov 4, 2025

Uh oh!

vercel bot commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NathanFlurry commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

How to use the Graphite Merge Queue

Uh oh!

claude bot commented Nov 4, 2025

Code Review

Positive Observations ✓

Concerns & Suggestions

1. Potential Race Condition

2. Type Safety

3. Missing Tests

4. Documentation

Questions

Verdict

Uh oh!

claude bot commented Nov 5, 2025

Code Review

Positives ✓

Suggestions for Improvement

Security & Performance

Code Style

Final Assessment

Uh oh!

claude bot commented Nov 5, 2025

Pull Request Review

✅ Strengths

🔍 Observations & Suggestions

1. Type Safety Consideration

2. Consistency Across Drivers

3. Potential Race Condition

4. Testing

📝 Minor Style Notes

🎯 Summary

Uh oh!

claude bot commented Nov 5, 2025

Code Review: PR #3360 - Log runner id with actor logs

Summary

Positive Aspects

Issues & Recommendations

1. Type Safety Concern - Return type could be more specific

2. Inconsistent Implementation - Missing implementation in Cloudflare Workers driver

3. Missing Test Coverage

4. Documentation Missing

5. Minor: Log Key Naming Convention

Security & Performance

Overall Assessment

Uh oh!

claude bot commented Nov 5, 2025

Code Review

Summary

✅ Positive Aspects

🔍 Observations & Questions

📝 Minor Suggestions

🎯 Test Coverage

Security & Performance

Conclusion

Uh oh!

claude bot commented Nov 5, 2025

Code Review: Add Runner ID to Actor Logs

Summary

Positive Observations

Issues & Recommendations

1. Type Safety Concern (Minor)

2. Missing Implementations (Medium Priority)

3. Potential Timing Issue (Low Priority)

4. Test Coverage (Medium Priority)

Security Considerations

Performance Considerations

Code Style

Overall Assessment

Uh oh!

vercel bot commented Nov 4, 2025 •

edited

Loading

NathanFlurry commented Nov 4, 2025 •

edited

Loading

graphite-app bot commented Nov 5, 2025 •

edited

Loading