fix(networks): mark tronshasta inactive to stop timelock auto-execution failures - #2267
Conversation
…on failures Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 2 included reviews per hour; 0 remain after this review. WalkthroughThe ChangesNetwork status configuration
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This localized configuration change excludes the inactive tronshasta testnet from scheduled timelock execution checks; no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.) Full details: Description checkExplanation The description is detailed and covers the task rationale, root cause, implementation, verification results, scope, and checklist sections. The unchecked test item is reasonable for a one-line configuration fix, and the reviewer checklist is appropriately left for the reviewer. ✨ 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 |
Which Linear task belongs to this PR?
None — single-line config fix, labelled
trivialper the carve-out in.agents/context.md.Why did I implement it this way?
Timelock Auto Executionhas failed on every scheduled run since 2026-08-24 16:21 UTC (23+ consecutive runs, one Slack alert each in#dev-sc-timelock-executions).Root cause: PR #2252 (EXSC-818 deploy-log pruning) deleted
deployments/tronshasta.json, buttronshastawas stillstatus: "active"inconfig/networks.json. The auto-executor iterates active networks;fetchPendingForNetworkcallsgetDeployments, which throws when the deployments file is absent rather than reporting "no timelock here":The guard at
execute-pending-timelock-tx.ts:240exits 1 when zero networks have pending work and at least one failed to fetch. That is why the alerts started ~8h after #2252 merged: until 16:05 UTC there was genuine pending work (injective + plasma), so the tronshasta error stayed a warning. The moment the queue drained, every run began failing.No timelock work was ever missed — this was pure false-alarm noise.
Fix:
tronshastahas no deployed diamond, no deploy log, no Safe address, and nofoundry.tomlentry. It is a Tron testnet reached only through thecontracts-tronfork's TronWeb scripts, which do not readstatus. Marking itinactiveremoves it fromgetAllActiveNetworks()and therefore from the executor's network set, so no prefetch is attempted and the guard no longer fires.Verified:
tronshastaexcluded,tron(mainnet) still included.tronshastaappears in no other config — onlyconfig/networks.json. No deploy log, nofoundry.tomlentry, nowhitelist/clearSigningreference.bun test script/→ 1056 pass, 0 fail (48 files).config/networks.json(insertion-only one-line diff, per repo convention that JSON is not formatter-managed).Known follow-up (deliberately not in this PR): the underlying fragility remains —
getDeploymentscannot distinguish "no deployment log" from a real fetch error, so any future active network without a deploy log will break the cron the same way. Treating a missing deployments file as "no timelock deployed" infetchPendingForNetworkis the durable fix.Checklist before requesting a review
Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)