-
Notifications
You must be signed in to change notification settings - Fork 146
fix(pegboard): cache none runner pool errors too #3899
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 01-14-fix_engine-runner_handle_shutdown_close_codes_correctly
Are you sure you want to change the base?
fix(pegboard): cache none runner pool errors too #3899
Conversation
More templates
@rivetkit/cloudflare-workers
@rivetkit/db
@rivetkit/framework-base
@rivetkit/next-js
@rivetkit/react
rivetkit
@rivetkit/sql-loader
@rivetkit/virtual-websocket
@rivetkit/engine-runner
@rivetkit/engine-runner-protocol
commit: |
600206d to
55a38d5
Compare
19b864f to
166bf69
Compare
55a38d5 to
715b5e8
Compare
PR Review: fix(pegboard): cache none runner pool errors tooSummaryThis PR fixes a caching issue where runner pool states with no active error were not being cached. The fix introduces a separate cache entry type that can represent both error and non-error states, ensuring all runner pool states are cached regardless of error presence. Code Quality ✅Positive Changes:
Style Compliance:
Logic Analysis ✅Before: Only runner pools with active errors were added to the cache result, meaning pools with no errors were not cached at all. After: All runner pool states are cached (with error: None for healthy pools), then filtered when returning to maintain API compatibility. Key Benefit: This ensures the cache correctly represents "no error" states rather than having cache misses, which prevents unnecessary re-fetching of healthy runner pool states. Potential Issues 🔍1. Early Return Behavior (Lines 97-99) This early return means runners without workflows will not get cached entries. Depending on the semantics:
Question: Should runners without associated workflows be cached as "no error" states? Currently they result in cache misses. 2. Partial Results Handling (Lines 106-109) The code silently skips workflows not in the lookup map. While unlikely to occur, this could lead to incomplete cache entries. Consider logging at debug level for observability. 3. State Parsing Failures (Lines 115-127) When state parsing fails or returns None, the runner is skipped entirely rather than being cached as "no error". This maintains existing behavior but may cause cache thrashing for runners with corrupted state. Suggestion: Consider whether parse failures should cache a default "no error" entry to prevent repeated parse attempts on every request. Performance Considerations ✅
Security Considerations ✅
Test Coverage
|
715b5e8 to
d6cf484
Compare
7ae571e to
9d5adb3
Compare
d6cf484 to
13e2511
Compare
13e2511 to
ce0f27d
Compare
9d5adb3 to
868b254
Compare

No description provided.