When you upload a ZIP, each file inside it becomes its own job under a parent, and you review the whole batch in one place. Approve & Finalize hands your edits to the files they belong to, each file is rebuilt, and the batch comes back as a single ZIP. That was the design.
What actually happened is that the spinner never stopped.
Twelve out of twelve
Nobody reported it. When we went looking, every ZIP project reviewed since the feature shipped at the end of July had ended the same way: twelve out of twelve.
The button distributed the edits, queued each file’s rebuild to run in the background, and marked the batch done. Done, but with no reviewed deliverable attached, and the review screen waits for both before it lets go. So it waited.
The spinner was the visible part. Two quieter consequences were worse. The batch download kept serving the ZIP from before review, and the delivery email attached that same file. And any file in the batch that nobody had edited stayed on hold indefinitely, because there was nothing to rebuild and so nothing ever released it. That blocked “Download all”, and the individual downloads with it.
Finalize now finishes before it says so
The batch now closes in a single pass. Files with edits are rebuilt then and there. Files without edits are released as they are, because approving the batch review is approving every file in it. A new ZIP is assembled from each file’s current deliverable, named after your original with a “_final_v2” suffix. Only then is the batch marked done. If one file fails to rebuild, the batch says which one, instead of reporting a success it has not had.
The rule underneath is simple enough to have been obvious in advance: “done” should be written by the step that did the work, not by the step that scheduled it.
Then the batch that never assembled
Ten days later, the same seam failed from the other side. A batch of eighty PDFs, one of the longest we have run: the last file alone took about forty-five minutes. All eighty were translated correctly. The ZIP never appeared.
Two things lined up. When the last file finished, it went to tell the batch to check whether it was complete, over a database connection that had been closed during those forty-five minutes. The call failed and nothing retried it. Meanwhile a cleanup process whose job is to rescue stalled work saw a parent that had been processing for a very long time and gave up on it, while one of its files was still running.
The completion check now reconnects when it needs to, and cleanup leaves alone any batch that still has files in flight. The stuck batch was assembled from its eighty finished files, with no retranslation and no second charge, and delivered.
What the two have in common
Both bugs lived at the point where independent files become one delivery. Every per-file check was green in both cases, because every file was fine. The failure was in the thing you actually download. That is also how we verified both fixes: not by the status of each part, but by downloading the batch and opening what came back.
Want this in your workflow? Try Fily with one file — no card, no demo form.