Repository navigation
frametx fixes - #293
frametx fixes#293
Conversation
![redpandabot[bot]](https://avatars.githubusercontent.com/in/3749543?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary
Adds EIP-8141 deploy-led validation prefixes (self-paying via a funded-pending-account buffer, sponsored via a minted account), a dedicated capability-probe wallet with a block-count timeout, and tolerant frame-receipt number decoding. The core generation/submission lifecycle traces clean; one real issue in --recipe replay mode.
Issues
- 🟡
scenarios/frametx-fuzz/generator.go:419— replayed deploy recipe is mutated in place, permanently degrading it — see the thread on that line
Reviewed @ 730e8d39
"You ain't gonna need it." — XP principle (YAGNI)
| if recipe.Prefix == PrefixDeploySelfVerify { | ||
| account, ok := env.pending.take(int(recipe.Index)) | ||
| if !ok { | ||
| recipe.Prefix = PrefixSelfVerify |
There was a problem hiding this comment.
🟡 replayed deploy recipe is mutated in place, permanently degrading it
recipeFor returns the shared s.replay pointer, and takeDeployedSender rewrites recipe.Prefix to PrefixSelfVerify when the pending buffer is empty — which it always is for a keyless replay, since a keyless transaction never appends funding frames. The first replayed deploy+self_verify transaction therefore permanently converts the recipe to self_verify (the deploy shape can never be reproduced), and since Run drives ProcessNextTxFn from concurrent goroutines, concurrent writes to the shared Recipe are also a data race.
No description provided.