fix: map 'timed out' race rejection to 504 instead of generic 500

[eprouveze]

What

The submit route's own 25s timeout race rejects with the message "Database operation timed out", but the error mapping below only checks for the substrings "timeout" and "deadline" — "timed out" (with a space) matches neither. So when a large-history merge blows the 25s window, the client gets the generic catch-all 500 "Failed to submit data. Please check your cc.json file format..." instead of the intended 504 "Request timed out. Please try again or submit smaller batches of data."

That message difference matters: the 500 sends users down a payload-format rabbit hole, while the 504 tells them the actual fix (smaller batches).

How I hit this

My account (eprouveze) has a ~188-day history. Since the #43/#79 per-machine merge deploy, mergeWithExisting runs one sequential daily_breakdowns round-trip per incoming day, so a full-history re-submit merging into an existing ~180-day record can exceed the 25s race. Every attempt returned the generic 500 with a payload that field-diffs identical to my last accepted submission (June 10, pre-deploy) — I only found the real cause by reading this route's source. Splitting the same data into ≤60-day chunks submits fine.

Notes

• Fix is intentionally minimal: add "timed out" to the existing substring check (plus a comment tying it to the race above).
• Possible follow-up (not in this PR): batching the per-day loop in mergeWithExisting (e.g. a single upsert on (submission_id, date)) would remove the timeout for long-history users entirely.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CprMNM6BjWgqLGcmCjZVZJ

[vercel]

@eprouveze is attempting to deploy a commit to the sculpt Team on Vercel.

A member of the Team first needs to authorize it.

[nikshepsvn]

Correct fix, and correctly scoped — you spotted that "Database operation timed out" matches neither includes("timeout") nor includes("deadline") back in early July, which is the same root cause #93 hit weeks later. This sat open longer than it should have; apologies for that.

Superseded by #100, which uses /timeout|timed out|deadline/i for the same effect and then removes the race that produced the message in the first place — the 25s Promise.race never cancelled its writes, so the data committed while the request reported failure. Your match stays in as defence for timeouts raised by the database client itself.

#100 also fixes the branch just below the one you touched: "Failed to query/update/create" were in the validation error list returning 400, so genuine infrastructure failures were being reported to users as a malformed cc.json too.

Closing in favour of #100. Thanks for the report and sorry it took a while to land.

[nikshepsvn]

Closing as superseded by #100, now merged. See the review comment above for what carried over and what changed.