magicblock-labs / magicblock-labs/redsuite
Validate program upgrades during execution and cloning
@bzawisto is already working on this.
Since Sep 11, 2026.
- Dominant language
- Rust
- Stars
- 1
- Forks
- 0
- Avg merge
- 3h 58m
- Merged PRs (30d)
- 48
Description
## Outcome
An upgrade must not cause MBV to execute an inconsistent combination of program metadata and executable bytes, or continue using an obsolete executable after fresh materialization is established.
Existing loader tests verify supported formats, not an upgrade occurring while the program is in use.
## Scope
Provide two versions of a fixture program with clearly different observable effects. Continuously invoke version A, upgrade it to version B on base, and delay MBV’s program/programdata fetch responses or notifications.
During the delay, issue further invocations and cold-clone requests. Then release fresh observations and verify convergence to version B.
Keep this on the supported upgrade path; do not assume every ER execution switches at the exact instant the base upgrade lands.
## Acceptance criteria
- [ ] Every successful invocation has a valid A or B effect, never a mixed or malformed result.
- [ ] Loading and execution failures leave no partial program-state changes.
- [ ] Once fresh materialization is established, subsequent invocations consistently execute B.
- [ ] Reports identify the base upgrade transaction, held observations, observed versions, and convergence point.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.