The Part I Thought Would Be Simple
I thought creating a job and attaching its documents would be simple. Then I started asking what happens when only half the work succeeds, and how to safely finish the rest.
I’ve been working on a workflow that creates a job from an incoming task and connects its documents. It sounds simple: save the job, link the files, and move on.
But I kept coming back to one question. What happens if the job is saved, but linking its documents fails?
The job exists, yet someone opening it might not have the files they need. Calling the operation a success would hide that problem. Calling it a failure would ignore the work already done.
I had to stop thinking about it as one operation with one result. Creating the job and completing its attachments were two separate things.
That changed how I thought about retries too. “Just try again” sounds reasonable, but what should happen again? Starting from the beginning could create another job. Repeating every step could duplicate links that already exist.
The recovery process needed to return to the existing job, check what had succeeded, and finish the missing work.
Then another detail made me pause. What if someone uploads a new document version before recovery runs?
Using the latest version might seem helpful, but it could change the information behind the job. The repair should connect the version the job was originally created with. That meant remembering both the document and its exact version.
If that version is unavailable, I’d rather show a clear problem than quietly open a different file.
I also found myself thinking about the person dealing with this after automatic retries have stopped. They need to know what happened, what is still missing, and whether they can safely try again. They should not have to guess whether clicking “retry” will create a duplicate.
I started with a fairly ordinary task: create a job and attach some documents. The interesting part turned out to be everything that could happen between those steps.
It reminded me how much of software design lives in unfinished work. The normal flow matters, but so does leaving enough information for someone to understand where things stopped and finish them safely.