My Image Timed Out but Higgsfield Had Already Finished It

Timeout after 6m0s; last status "in_progress" was the message on screen.

The runner counted the image as a failure. Nothing had downloaded. From my side, the job looked dead.

That combination is dangerous because it makes regeneration feel like the obvious next move. The command failed, there is no image on disk, and the queue has already taken six minutes. It is easy to assume that Higgsfield never finished the work.

That assumption would have cost me another credit.

The job was not lost. Higgsfield was still processing it on the server. It finished later, the complete image existed there, and the original credit had already been charged.

The failure belonged to the client waiting for the result. It did not belong to the generation itself.

One word was hiding two different states

My runner called the result FAIL.

That label was technically useful, but it was too broad. It told me that the command had not completed its expected local sequence. It did not tell me why.

In this case, the command was supposed to wait for Higgsfield, receive the completed result, and download the image. The six-minute waiting limit expired while the remote status still said in_progress. The download step never happened, so the runner recorded a failure.

But the timeout did not cancel the server job. Higgsfield kept working.

That creates an awkward split between what exists locally and what exists remotely. My folder says the image is missing. The server says the job eventually completed. The billing record follows the server, not the empty space in my folder.

If I treat every local failure as a failed generation, I pay again for work that has already been done.

I checked the server before generating again

The recovery started with one rule: do not relaunch anything yet.

I listed the 20 most recent generation jobs:

generate list --size 20

The timed-out job was among those recent records. It had become an orphan from the local runner’s point of view. The command that created it had stopped waiting, but the remote job had continued without that local process following it to completion.

Finding a completed job in the recent list still did not tell me which downloaded file belonged to the missing slot. I needed to compare the server results against the images already present on disk.

So I downloaded each available URL from the recent jobs and calculated its MD5 hash. Then I compared those hashes with the images already in the project folder.

The matches were images I already had.

The one that did not match any local image was the missing generation.

That was the whole recovery. I did not rewrite the prompt. I did not rerun the generation. I did not spend another credit. I identified the completed remote result by eliminating every result already represented on disk.

The cost of recovery was zero credits.

The status determines the fix

A timeout and a moderation rejection can both appear under the same failure count, but they require different responses.

A timeout with the last status still showing in_progress means the client stopped waiting. It does not prove that the server stopped generating. The next step is to inspect recent jobs and reconcile them with the files already downloaded.

A moderation rejection with status: nsfw is different. That job needs another attempt with a changed prompt. There is no completed image waiting to be recovered through the recent-job list.

Putting both outcomes into one undifferentiated FAIL bucket encourages the wrong behavior. It turns a recoverable download problem into a second paid generation.

The useful question is not, “Did my command fail?” It is, “What state did the remote job reach?”

Those are not the same question.

Why checking filenames was not enough

The recovery depended on content comparison.

The recent-job list contained multiple results, and the local folder already contained multiple images. Looking at the list alone showed that work had completed, but it did not identify the orphan with certainty.

The MD5 comparison gave me a mechanical answer. Every server image whose hash matched a local file was accounted for. The unmatched hash pointed to the image that had completed but never downloaded during the timed-out command.

This matters most when several generations are close together. The useful evidence is not the runner’s final label. It is the relationship between recent server results and the actual files on disk.

The server record shows what Higgsfield finished. The hashes show what I already possess. The difference between those two sets is what needs to be recovered.

The rule I use now

A timeout is a waiting failure until I prove it was a generation failure.

When I see Timeout after ...; last status "in_progress", I stop before relaunching. I inspect the recent jobs, download their result URLs, compare their MD5 hashes with the images on disk, and recover the unmatched file.

Only a confirmed rejection, such as status: nsfw, sends me back to the prompt.

Today, search your own runner or notes for places where timeout and moderation rejection share the same FAIL path. Separate them before the next timed-out image asks you to pay twice.

---

Every fix in this article was paid for with a mistake first. Better on my film than on your brand.