Repository navigation
feat(core): implement configurable extension jitter (#500) - #547
AbdulmalikAlayande merged 1 commit into
Conversation
|
@Peolite1 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
📝 WalkthroughSummary by CodeRabbit
WalkthroughChangesExtension jitter scheduling
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant CLI
participant runAutoExtensions
participant ExtensionTasks
participant RPC
CLI->>CLI: Parse --extension-jitter-ms
CLI->>runAutoExtensions: Provide EXTENSION_JITTER_MS
runAutoExtensions->>ExtensionTasks: Precompute queued contracts
ExtensionTasks->>ExtensionTasks: Apply random per-task delays
ExtensionTasks->>RPC: Submit extension transactions
Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![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
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/core/extension.ts`:
- Around line 343-346: The jitter in the eligibleTasks scheduling at
src/core/extension.ts lines 343-346 must enforce nonzero separation between
submissions rather than starting independent timers; retain the configured
extensionJitterMs upper bound and update the scheduling logic accordingly. In
tests/core/extension.test.ts lines 869-877, record each submission timestamp and
assert that consecutive submissions are separated, replacing the
total-runtime-only assertion.
In `@src/index.ts`:
- Around line 32-33: Validate the CLI jitter option in src/index.ts near the
option definition as a non-negative integer strictly below the configured
polling interval, rejecting invalid values. Apply equivalent validation or a
safe cap to the environment-derived jitter in src/core/extension.ts around the
extension submission configuration so direct environment values cannot delay
submissions beyond the polling cycle.
- Around line 55-59: Update the extensionJitterMs environment-variable
assignment after program.opts() to check whether opts.extensionJitterMs is
undefined rather than relying on truthiness, so an explicit zero value
overwrites any inherited EXTENSION_JITTER_MS.
In `@tests/core/extension.test.ts`:
- Around line 813-842: Update the test case around runAutoExtensions to
explicitly unset EXTENSION_JITTER_MS before execution and restore its prior
environment value afterward. Use the test’s existing environment helper pattern,
ensuring cleanup occurs even if the assertion or async operation fails, while
preserving the duration assertion for the default no-jitter behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: ab94e270-5fc9-47af-97d2-4eaceb382b81
📒 Files selected for processing (3)
src/core/extension.tssrc/index.tstests/core/extension.test.ts
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| - | - | Generic High Entropy Secret | ded54f4 | tests/commands/guard-cli-export-import.test.ts | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
|
Merged as 5bc1e7a on |
2 participants
What does this PR do?
This PR implements a configurable jitter window for auto-extension submissions, which is applied when multiple extensions are queued in a single daemon cycle. Closes #500.
Why?
If many watched contracts cross their extension threshold in the same cycle, the daemon previously submitted all extension transactions synchronously back-to-back. At fleet scale, this can cause self-inflicted network fee spikes. Spreading the submissions out randomly within a configured window (using the new opt-in
--extension-jitter-msflag) avoids these thundering-herd fee pressures while maintaining the correct rate-limit behavior.Does this touch secret-key handling or transaction submission?
This touches
src/core/extension.ts(specificallyrunAutoExtensions). A small asynchronous delay is introduced immediately prior to acquiring secret keys and submitting the transaction, spacing out the concurrent promises when jitter is enabled.Checklist
npm test)npx tsc --noEmit)npm run lint)console.login core logicCloses #500