The generator failed, committed half its writes, then used them to block the retry

A developer writing up a bug for DEV's Summer Bug Smash injected a failure into the third write of Formbricks' AI example-response generator, and watched the action reject while the database kept most of what had already happened [s1-c3][s1-c4]. The interesting part is not the orphaned rows. It is that the leftover rows then triggered the feature's own precondition and locked the user out of retrying [s1-c7].

Formbricks is an open-source experience-management platform for surveys and response analysis, and its Survey Summary can generate example responses so a team can look at the analytics before real data exists [s1-c1]. Behind the button, the persistence path is a loop: create a tag, create a display, create a response, evaluate quotas, link the tag, repeat [s1-c2]. Each completed piece could commit before the next one began [s1-c2]. One generation writes a generated-response tag, a Display and a Response per synthetic submission, response timestamps, quota-evaluation links, tag links and extra impression-only Displays [s1-c9]. Production generates 20 of them [s1-c10].

With the failure injected during response 3, the author reports that responses 1 and 2 survived, along with three displays, a newly created tag and two tag links [s1-c4]. The third display had already been written before response creation failed [s1-c5], which leaves one display with no response attached to it [s1-c20]. The enclosing action rejected, but there was no enclosing database transaction capable of undoing the earlier work [s1-c22].

That is a cleanup problem until you add the guard. Formbricks only permits example generation while a survey has zero responses [s1-c6]. After the rate-limit window elapsed, the retry hit that check, and the two surviving responses were enough to fail it [s1-c7][s1-c21]. The operation reported failure, mutated the database, and then cited the mutation as the reason it could not be attempted again [s1-c7].

The framing worth stealing here is the author's: a user-level operation does not become atomic because every helper has a transaction somewhere inside it [s1-c11]. If helper A commits, helper B commits and helper C rolls back, the database has correctly protected three operations, and the user asked for one [s1-c11]. The stated invariant is one request, one persistence outcome: the whole synthetic dataset commits, or nothing from that attempt remains [s1-c8].

The obvious fix did not survive contact. Wrapping persistence in one outer Prisma transaction and passing its client into the writes passed the first rollback test [s1-c15]. Then the author constrained Prisma to a single database connection and the test expired after about five seconds [s1-c16]. The outer transaction held the only connection, while organization, workspace, survey and quota services were still reading through the global Prisma client and asking the pool for a second one that did not exist, so the transaction waited on code inside itself [s1-c17]. A longer timeout would only have lengthened the wait; the boundary had been drawn in one function while the call graph crossed it [s1-c18]. The revised implementation loads stable survey, quota and workspace-to-organization context once through the transaction client [s1-c19].

The reproduction used a deterministic four-response dataset in place of the model call, with the final validation exercising the production-sized batch of 20 [s1-c12], and a baseline characterization test pins the unpatched behaviour [s1-c13]. The author is explicit that this demonstrates a mechanism, not a frequency: it did not come from a production incident report, and the cost is unknown [s1-c14].

What to watch: whether the patch lands upstream, and whether the pattern shows up elsewhere in the same codebase. Any multi-write path guarded by a "only if zero rows exist" precondition has the same failure shape available to it.