Pin versioned deploy constants per soldeer tag (dex pattern)#246
Conversation
Adopt raindex's versioned-deploy-constants pattern so a bytecode-changing PR isn't blocked on the single "current" deploy constant. Today any source change to the deployed contracts forces bumping ZOLTU_DEPLOYED_DECIMAL_FLOAT_ADDRESS / DECIMAL_FLOAT_CONTRACT_HASH, which then makes LibDecimalFloatDeployProd red until the new bytecode is deployed — a premerge chicken-and-egg. Pinning a frozen constant suite per published soldeer tag records each release so the deploy verification tracks published versions, not the bleeding edge. - LibDecimalFloatDeploy.sol: add frozen *_0_1_1 deploy constants for the published 0.1.1 soldeer tag (log tables + DecimalFloat address/codehash). - script/check-published-deploy-constants.sh: query the soldeer registry and list any published tag missing its pinned suite (prints OK/MISSING/SKIP). - LibDecimalFloatDeployTaggedConstants.t.sol: FFI test asserting every published tag has its full suite; skips if the registry is unreachable. Additive only (no bytecode change) — existing deploy/prod tests are unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 57 minutes and 47 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughAdds four frozen deployment constants (addresses and codehashes for log tables and DecimalFloat) pinned to soldeer tag ChangesVersion-pinned Deploy Constants and Coverage Enforcement
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related issues
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
|
Companion org-wide enforcement: rainlanguage/rain-org-health#4 adds a |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@script/check-published-deploy-constants.sh`:
- Around line 20-23: The curl command in the versions variable assignment lacks
timeout configuration, which can cause the script to hang indefinitely if the
network connection stalls. Add `--connect-timeout` and `--max-time` flags to the
curl command that calls the Soldeer API endpoint for rain-math-float to ensure
the request fails gracefully if the network is unresponsive, preventing the test
run from hanging.
🪄 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
Run ID: d2e46c5e-be3b-4baa-a8af-4bbb941d1102
📒 Files selected for processing (3)
script/check-published-deploy-constants.shsrc/lib/deploy/LibDecimalFloatDeploy.soltest/src/lib/deploy/LibDecimalFloatDeployTaggedConstants.t.sol
A stalled registry call could otherwise hang the FFI test indefinitely. --connect-timeout/--max-time + a bounded retry. (CodeRabbit) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
|
Human-approved (thedavidmeister, sha fbf9de3); merging. |
|
human-approved; merging (admin: only failing checks are testProdDeployment* — DecimalFloat not deployed on prod chains, a known deploy-pinned condition unrelated to this PR's diff) |
|
@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment: S/M/L PR Classification Guidelines:This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed. Small (S)Characteristics:
Review Effort: Would have taken 5-10 minutes Examples:
Medium (M)Characteristics:
Review Effort: Would have taken 15-30 minutes Examples:
Large (L)Characteristics:
Review Effort: Would have taken 45+ minutes Examples:
Additional Factors to ConsiderWhen deciding between sizes, also consider:
Notes:
|
|
Tip For best results, initiate chat on the files or code changes. SIZE=M |
2 participants
What
Adopt raindex's versioned deploy-constants pattern, matching the soldeer-published versions.
Why
LibDecimalFloatDeployProd.t.solforks each chain and asserts the deployed DecimalFloat / log-tables address+codehash equal the constants inLibDecimalFloatDeploy.sol, whileLibDecimalFloatDeploy.t.soldeploys the current bytecode and asserts it equals those same constants. So any source change to the deployed contracts forces bumping the single "current" constant (to satisfy the local test), which makes the prod fork test red until the new bytecode is deployed — the premerge chicken-and-egg.Pinning a frozen constant suite per published soldeer tag (like raindex's
LibRaindexDeploy.sol+LibRaindexDeployTaggedConstants.t.sol) records each release's deployment independently of the current bytecode, and a registry-backed completeness test enforces that every published tag stays pinned. Deploying remains the routine deterministic-Zoltu step (Manual sol artifacts).Changes (additive — no bytecode change)
LibDecimalFloatDeploy.sol— frozen*_0_1_1constants for the published0.1.1soldeer tag (log tables + DecimalFloat address & codehash), pinned as literals so they keep referencing 0.1.1 after the current constants advance.script/check-published-deploy-constants.sh— queriesapi.soldeer.xyzfor every publishedrain-math-floatversion and lists any tag missing its suite (OK/MISSING:…/SKIPwhen unreachable).test/src/lib/deploy/LibDecimalFloatDeployTaggedConstants.t.sol— FFI test assertingOK;vm.skiponSKIP.Validation
forge build✓,forge fmt --check✓testAllPublishedSoldeerTagsHaveAFullConstantSuite✓ (registry → 0.1.1 → suite present → OK)testDeployAddress/testDeployAddressLogTables✓ (additive, no bytecode change)Note: this PR doesn't by itself flip a bytecode-changing PR's fork prod test green — that's resolved by deploying (the easy deterministic step). It establishes the versioned-constant discipline + a premerge completeness gate, faithful to dex.
🤖 Generated with Claude Code
Summary by CodeRabbit
Tests
Chores
New Features
0.1.1soldeer tag (log tables and DecimalFloat addresses and code hashes).