Rollback-tested releases

Catch stale data before rollback: GitLab Duo proposes a fix, and protected CI checks whether the latest saved edit survives.

Comment

Backend engineers can ship code that passes its own tests but leaves no safe way back. When a new version changes how it stores an address, the old version may stop reading it. Even a plausible dual-write repair can silently return stale data after rollback.

Rollback-tested releases makes that failure visible. Against real PostgreSQL, the demo creates 10 Example Street with the new writer, rolls back, saves 21 Sample Road through the old version, and moves forward again. The naive repair returns the old address. The supplied compatibility control preserves the latest acknowledged edit.

The evidence view compares expected and observed values across old -> new -> old -> new, with retries, stale-write checks and retained attempt history. It gives a backend engineer a concrete reason to reject an unsafe change and a reproducible check for the repair.

GitLab Duo Agent Platform investigated one seeded merge request through five API reads and proposed a minimal read-precedence patch. After human review, separate protected GitLab CI admitted the MR sources, built and scanned the exact persistence workers, and ran the PostgreSQL checks. The seeded source passed 15 of 16 checks and reproduced the stale edit. The recorded proposal passed all 16.

The 16 checks cover nine version reads/writes, four duplicate deliveries, two stale updates and one record count. The decisive native check expects 21 Sample Road after rollback accepts that edit. The seeded reader returns stale 20 Sample Road; the reviewed proposal returns 21. Dual writing alone leaves the newer alias stale. Duo's patch changes read precedence, and the other 15 checks keep passing. The linked comparison shows every expected and observed value.

This is Start Fresh: Assisted. Duo proposes the repair, protected CI verifies it, and a human decides whether to release. The project touches Verify, Package and Secure.

TypeScript, Node.js, Fastify and PostgreSQL provide the app and retained evidence. Google Cloud Run hosts the live synthetic replay, and Cloud SQL stores its orders and evidence. Docker isolates the verification workers, GitLab CI runs the protected and portable checks, and Playwright tests the browser journeys. Codex assisted implementation, testing and documentation. The demo narration uses the AI-generated HeyGen Marcia voice.

The public judge guide links the exact patch, native session, pipeline capture and paired result reports. The source includes the MIT license, setup/reset instructions and meaningful tests. The preserved video candidate 26550c8 passed 201 application tests, 62 browser checks and 35 control tests. The Google Cloud extension passed 207 application tests, 62 browser checks and 35 control tests; public source CI runs its separate portable gate.

The live Google Cloud app lets judges run the same supplied synthetic controls without installing anything. Its naive fixture reproduced 15 of 16 checks and its compatibility control passed all 16. Fourteen live API checks verified source identity, duplicate handling, session isolation and order/report persistence across a process restart. The deployed image uses source c222204; the video and recorded native proof preserve candidate 26550c8. Deployment code and exact receipts are public.

The demonstration combines synthetic replay with recorded native evidence for one persistence-worker case. Accepted live native application collection, automatic event admission and production release remain future work. We have not measured time saved, adoption or sustainability gains. The linked evidence explains the tested scope and known limits.

Built With

Share this project:

Updates

Submission history