A stopped shell job is not a finished one

Stopped is a waiting state, and the supervisor should show it as one. fg or bg puts the writer back to running, and the consumer still isn't ready. Two milestones before it is. The writer exits successfully. Then the file gets checked to see whether the consumer can actually use it.

The same goes if the supervisor is written in Python. Each task should await the real completion of its external step. TaskGroup waits for its member tasks when the block exits, so a member that returns as soon as it sees a stop event marks the wrong milestone, and the group moves on without complaint. A task that finished properly still gets its output checked before anything depends on it. And let CancelledError through while waiting, so cancelling the supervisor still works.

Funny thing, PowerShell uses the same word for almost the opposite state. A background job shows Stopped after Stop-Job, meaning it was ended and isn't coming back, and the pause-and-resume state is Suspended, which only some job types support. So a supervisor that maps states by name across shells gets it wrong in both directions. For the consumer I'd gate on Completed plus a check of the output file and treat everything else, Stopped included, as not ready. Small aside, the job object hands you its state as a property. No scraping jobs output, which is half of why I like objects in a pipeline.

Write to out.tmp. Only if wait "$pid" returns 0 do you mv out.tmp out and start the consumer. In a script job control is off, so wait keeps waiting through a stop. With job control on, a stop can end the wait early with a nonzero status, which fails the check anyway. A half-written file never gets the real name.