Automated Cloning, Reattack and SBOM Flows Failing

Update timeline

1. resolved Aug 20, 2026, 04:24 AM UTC

   Some of our automated flows are currently failing: repository cloning, reattacks on automatic reports, and SBOM requests are not completing. The cause has been traced to an issue in our infrastructure, and our team is already working on restoring these flows. Existing information remains complete and intact, and there is no impact to security or to any other part of the platform.

2. postmortem Aug 20, 2026, 04:27 AM UTC

   ### Postmortem #### Impact Some users experienced failures in several of our automated flows: repositories could not be cloned, reattacks on automatic reports did not run, and SBOM requests were not fulfilled. The issue started on UTC-5 26-08-18 09:07 and was reactively discovered 6 hours \(TTD\) later by a staff member from the hacking team who noticed that reattacks on automatic reports had been queued for more than three hours without progressing. The problem was resolved in 1.2 hours \(TTF\), resulting in a total window of exposure of 7.2 hours \(WOE\). * **Repository cloning**: cloning executions did not run, so repository contents were not refreshed during the window. * **Reattacks on automatic reports**: reattack requests were accepted but stayed queued without being executed. * **SBOM requests**: requested SBOM files were not generated or delivered. #### Cause These three flows are not run directly by the platform. The platform builds and enqueues an execution, and a set of state machines then carries out the actual work; the handoff happens at a stage called `batch_dispatch`. A change updated the definition of those state machines, along with the components downstream of them, to a new format for passing the parameters of each execution[.](https://gitlab.com/fluidattacks/universe/-/merge_requests/110512).) The component that sits upstream, the one inside the platform that generates and enqueues the executions, was not updated in the same change, so it kept dispatching against the previous version. From that point on, the parameters it sent no longer matched what the state machines expected, and every execution it enqueued failed at the handoff stage instead of running. The mismatch was not caught before reaching production because this kind of infrastructure change is not currently covered by an end-to-end test in our continuous integration pipeline, and the developer making the change did not have full visibility into how the two sides of the flow depend on each other. #### Solution The version of the state machines referenced by the platform's dispatching component was updated to the latest one, bringing both sides of the flow back into agreement[.](https://gitlab.com/fluidattacks/universe/-/merge_requests/111060).) Cloning, reattack and SBOM executions resumed processing immediately afterwards, including the work that had accumulated while the flows were failing. To prevent a recurrence, the team will evaluate testing alternatives that can detect this class of version mismatch from the continuous integration pipeline, before a change of this kind reaches production. #### Conclusion This incident showed that a change to the state machine definitions and a change to the component that dispatches their executions must be rolled out together, and that nothing in our pipeline currently verifies that the two remain compatible. An end-to-end test covering the dispatch path, together with clearer documentation of how the flow works from end to end, would have surfaced the mismatch before any user was affected. **MISSING\_TEST < COMMUNICATION\_FAILURE < INCOMPLETE\_PERSPECTIVE**