-
-
gitlab-duo-repair-passed
Inspiration
A small API change can break applications that depend on existing response fields. I wanted to shorten the path from detecting a compatibility regression to preparing a tested repair for human review.
What it does
API Compatibility Repair combines deterministic contract checks with a custom GitLab Duo Agent Platform flow.
In the demonstrated orders API, a deliberate change replaces the legacy total field with a new amount field. CI detects that total is missing. A developer mentions the custom flow on the merge request, and Duo reads the contract and client, reproduces the failure, repairs the service, runs validation, and creates a separate draft repair merge request.
The repair preserves the new amount field while restoring total with the same numeric value. The unchanged legacy client works again.
This is a supervised workflow: the developer reviews the outcome. The flow does not automatically merge or deploy the repair.
How I built it
I built the service with Python and FastAPI, an HTTPX legacy client, saved JSON Schema contracts, and pytest tests.
GitLab CI runs three jobs: compatibility, tests, and demo scenarios. The custom Duo flow uses tools to read merge requests and files, edit the service, run commands, and create a repair merge request.
The flow is instructed to preserve contracts, clients, tests, and CI configuration. These instructions are behavioral guidance; the final diff and validation results still require review.
Challenges I ran into
The default remote execution image used Python 3.9, while the application needed Python 3.12 or newer. I fixed the setup by provisioning Python 3.12 through uv while retaining GitLab's default execution image and sandbox configuration.
Another challenge was preserving both behaviors: restoring the old field must not remove the new feature. Feature tests check amount, while the saved contract and existing client check total.
Accomplishments
The real Duo session created draft repair MR !5, changing only app/main.py and app/orders.py.
Compared with the broken source branch, the contract, client, tests, checker, demo, dependencies, and CI remained unchanged in the repair.
All 23 tests and all three GitLab CI jobs passed at repair commit 0444cd17. I also tested the repaired service over local HTTP: both fields returned matching values, and the original client printed Order #1: 150.00 SAR.
The repair remains a draft targeting the deliberate regression branch.
What I learned
Agentic repair benefits from an explicit contract, a concrete consumer, and tests for the intended new behavior. The actual agent session, repair diff, and passing pipeline provide stronger evidence than a handwritten reference demo.
What's next
I plan to expand contract coverage and evaluate additional route and type changes on more realistic APIs.
The current prototype checks two saved request/response cases. It does not prove compatibility for every endpoint, arbitrary input, or semantic change.
Evidence and testing
Installation instructions are in the repository README. To test the demonstrated repair after setup, switch to repair/mr2-restore-total and run scripts.check_contracts and pytest using the project virtual environment. Expect a compatible result and 23 passing tests. The main branch contains 20 baseline tests.
The local repaired demo scenario is a handwritten reference. The linked Duo session and MR are the actual agent repair evidence.
Log in or sign up for Devpost to join the conversation.