Inspiration
A background job finishes, but its acknowledgement disappears. Retrying blindly can repeat useful work; turning retries off can leave the job unfinished. Developers need a way to recover safely, see what actually happened, and improve efficiency without quietly losing results.
VertriX Stormbreaker makes this trade-off observable. Its principle is simple: a saving counts only after the useful work is independently verified.
What it does
Stormbreaker extends the MIT-licensed bull-board project with a real BullMQ worker, durable transactional receipts and coordinated recovery. Stable tenant-scoped identities let the system find a completed operation instead of repeating it. Bounded retries and authoritative receipt lookup handle temporary failures and ambiguous responses; an unresolved outcome remains explicitly unresolved.
The English web application guides visitors through Overview, Try it, Results and Evidence. Six scenarios cover normal operation, a temporary outage, a lost response after commit, permanent rejection, an unknown outcome and tenant isolation. Visitors can compare coordinated recovery with the baseline, inspect each result, and try deliberately unsafe policies to see the correctness gate reject them.
From an existing project to a complete GitLab workflow
Path B: Bring Your Own. The original project is bull-board, MIT licensed, v9.10.4 at commit 675966251c30e3d3c4ef61b7d061310a54c220c0. Its queue dashboard is the upstream foundation. Stormbreaker's recovery workload, verification contracts, GitLab Duo integration, delivery controller and Google Cloud deployment were added for this hackathon. The demonstrated incidents are our workload fixtures, not vulnerabilities attributed to the upstream project.
Before this integration, diagnosing a policy, checking a fix, reviewing and merging it, deploying it and confirming the live result were separate operator tasks. The recorded Hands-off workflow connects them after one initiation:
- An issue describes a concrete tenant-isolation regression.
- A native GitLab Duo flow produces a new policy correction and merge request.
- Protected CI independently checks the permitted change, exact source identity and full workload contract.
- The controller automatically merges the accepted candidate.
- A signed request deploys that same artifact to Google Cloud.
- HTTPS identity checks, a positive comparison and an expected negative control verify the running application.
- A completion receipt returns to the originating issue.
No manual merge or deployment occurs in the middle. The controller uses bounded attempts, persistent state and exact artifact identities; the code writer does not decide whether its own correction passed.
What we verified
The filmed run on 26 October links issue #8 → Duo session 10066668 → MR !10 → pipeline 2990489553 → deployed commit a583dddb… → live verification → final receipt. The application suite passed 218 tests. The automation suite passed 182, with one expected platform-specific skip.
On the six-scenario controlled workload, coordinated recovery used 11 protocol operations versus 38, with all correctness checks passing. Against a separate native BullMQ implementation with exponential retries and stable idempotency keys, six measured pairs completed the same 360 verified documents with 13.91% fewer operations and 59.89% less wall time. The repository includes the comparator and measurement methodology.
A separate six-pair Mac campaign verified 1,080 documents per configuration and measured a positive mean combined CPU/GPU/ANE energy difference of 0.1385–0.3680 joules per verified document under the declared background-sensitivity analysis. The SCI documentation accounts for functional units, model assumptions, embodied emissions and optimization overhead. These scoped measurements and estimates are reported separately: operation counts are not electricity readings, and the project does not claim a measured net carbon saving for the entire cloud deployment.
How we built it
Node.js, BullMQ, Valkey and SQLite power the workload and durable receipts. GitLab issues, native Duo flows, merge requests and protected CI form the repair and verification path. The delivery controller and signed target integration carry accepted artifacts to a live HTTPS application on Google Cloud Compute Engine. Deployment scripts, service configuration, tests and operator instructions are included in the public MIT repository.
The difficult part was preserving the same identity across failure, repair, merge and deployment. Tenant isolation, late responses, retry budgets and receipt reconciliation had to remain correct even when an apparently cheaper policy failed to finish the work. Independent positive and negative controls make that distinction visible.
Reuse and next steps
The recovery contract exposes invoke and lookup; a new workload supplies its adapter and correctness oracle. The repository includes SQLite and HTTP examples, adoption instructions and reproducible verification commands. A future backend can reuse the workflow while implementing its own idempotency and receipt guarantees.
Try the live application · Read the verified workflow · VertriX
Built With
- gitlab
- google-cloud
- node.js
Log in or sign up for Devpost to join the conversation.