fix(#2464): don't register the market until insurance has verified - #2536
Merged
Conversation
The batched launch STARTED the keeper-register call, then ran the M3b insurance
broadcast and its on-chain verification, then awaited the call. So the
registration request was in flight — and could already have completed — while the
check was still deciding whether the launch had failed.
A launch that threw "Insurance fund was not seeded" could therefore leave the
market listed and keeper-registered anyway: on-chain state, app registry, keeper
service and the user-visible result all disagreeing.
Fixed by making it a thunk invoked AFTER the insurance gate rather than a promise
started before it.
THE WINDOW IS UNCHANGED AND STILL SATISFIED, which is what made this fixable at
all. The source documents both bounds:
* after M3a — so a market is listed only once it actually holds collateral.
This is the ANSEM zombie: registration used to fire right after M1, and since
"create the market" always succeeds, EVERY failed launch left a listed,
unfunded, untradeable market behind.
* before M4 — StakeInitPool rotates marketauth away from the deployer, and
keeper-register's H1 check requires marketauth to still equal it.
The insurance check sits inside that window, so registration only had to move
later within it, not out of it.
THE COST IS LATENCY, stated rather than hidden: the round-trip no longer overlaps
M3b's broadcast, so the tail sits longer against the shared blockhash. That is
the right trade — the blockhash-expiry path already REBUILDS a not-yet-landed
tail tx against a fresh blockhash (TailTxDescriptor), whereas an incorrectly
published market has no equivalent undo.
Two existing source-position tests pinned the OLD ordering and are updated to
assert the invocation rather than the declaration — and TIGHTENED: the zombie
guard now also requires registration to follow the insurance gate, which is the
#2464 property itself.
Negative control: restoring the eager start fails both.
Launch suite: 3149 passed / 16 skipped / 0 failed.
Refs: #2464
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NgoNgagkvw7i5SSRC3FJ8D
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reachedNext included review available in 50 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2464.
The batched launch started the keeper-register call, then ran the M3b insurance broadcast and its on-chain verification, then awaited the call. So the request was in flight — and could already have completed — while that check was still deciding whether the launch had failed.
A launch that threw "Insurance fund was not seeded" could therefore leave the market listed and keeper-registered anyway: on-chain state, app registry, keeper service and the user-visible result all disagreeing. Exactly as reported.
Fixed by making it a thunk invoked after the insurance gate rather than a promise started before it.
The window is unchanged — which is what made this fixable
The source documents both bounds, and they are why it couldn't simply be moved anywhere:
StakeInitPoolrotatesmarketauthaway from the deployer, and keeper-register's H1 check requires it to still equal the deployer.The insurance check sits inside that window, so registration only had to move later within it, not out of it.
The cost, stated rather than hidden
Latency. The round-trip no longer overlaps M3b's broadcast, so the tail sits longer against the shared blockhash.
That is the right trade: the blockhash-expiry path already rebuilds a not-yet-landed tail tx against a fresh blockhash (
TailTxDescriptor), whereas an incorrectly published market has no equivalent undo.Tests
Two existing source-position tests pinned the old ordering. Updated to assert the invocation rather than the declaration — and tightened: the zombie guard now also requires registration to follow the insurance gate, which is the #2464 property itself.
Negative control: restoring the eager start fails both.
Launch suite: 3149 passed / 16 skipped / 0 failed;
tscclean.🤖 Generated with Claude Code
https://claude.ai/code/session_01NgoNgagkvw7i5SSRC3FJ8D