Flux ArtPreserve the verified result before tracing the late response
In a business system integrated with Flux Art, do not immediately recreate a task when it first shows success and later shows processing. First verify that the task_id and business version are the same, then inspect when each query was sent and returned. A slow older query may arrive late and overwrite the local display. This article covers status write-back design on the integrator side; it does not claim the platform returns responses in this order or that the browser display is remote truth.
Keep a separate record for every observation
Do not store only the last status field in the task table. For each query, record the task identifier, business version, local query sequence, request start time, response arrival time, response status, and necessary raw evidence. Keep credentials and sensitive parameters out of ordinary logs. The query sequence describes the order in which this system sent requests, not a server revision; even if a later query returns first, that does not prove it contains a newer remote state.
Use hypothetical responses to separate two timelines
Suppose query A is sent first and query B second; B returns success first, then A returns processing. This is not a measured result, but an input for reproducing a local overwrite bug. Acceptance checks should confirm that both observations remain recorded and that a verified success projection is not automatically downgraded to processing by an older non-terminal response. If a response belongs to another task_id, isolate the identity mismatch first; do not use the terminal-state rule below to conceal a task mix-up.
| Observation | Local display handling | Evidence to retain |
|---|---|---|
| Processing arrives after verified success | Do not downgrade automatically; mark as an older observation | Both query sequences and raw responses |
| The same success response arrives twice | Keep the result; do not store it twice | Deduplication identifier and existing file record |
| Success and failure conflict | Mark for review; do not rank states | Task identity and authoritative recheck result |
| Business version has changed | Do not overwrite the new version's display | Request version and current version |
| Response task identifier does not match | Isolate it; do not write to the current task | Difference between request and response identifiers |
| Query error contains no valid state | Preserve the last verified information | Error type and next review plan |
Store the observation log separately from the page display
The observation log can be append-only, while the page display is updated under explicit rules. For a terminal state already confirmed for the same task, do not let a subsequently arriving non-terminal state overwrite it directly; record that response as an older observation requiring explanation. If terminal states such as success and failure conflict, do not force a winner with a numeric ranking. Preserve the conflict, verify task identity, and query the authoritative interface again. Do not delete a result file already stored merely because one display regressed.
Control concurrent local writes together
A frontend check alone is not enough. Two backend processes may read the same old value and then each write it back. At the storage layer, use a transaction or conditional update to validate the current task identity, business version, and permitted transition together. Separating the check from the write leaves a race window. Record why a write was rejected so identity mismatch, version mismatch, and terminal-state conflict can be distinguished; rejecting a display update does not mean discarding the raw observation evidence.
Do not invent a version field for the API
Use https://flux-art.net/en/openapi/reference for current Flux Art interface fields and task-query methods. Fields such as observation_seq or a display version added by the integrator belong to its own system and must not be described as platform response fields. If the interface provides no comparable server revision, a client timestamp cannot substitute for one. Clocks on different machines may also differ, so timestamps are mainly for investigation, not a standalone truth test.
Give anomalous states a clear next step
The page can continue showing a verified successful result while routing the conflict to operations or engineering; an unverified conflict should be marked for review, not presented as resolved. Bound the number and interval of repeat queries, and follow response requirements when rate-limited. Refreshing the page should read the local projection, not automatically send a new creation request. A lost query, an unknown creation outcome, and a confirmed failure are three different situations.
Include late, duplicate, and mismatched responses in tests
At minimum, test six inputs: a late old non-terminal response, a duplicate identical response, conflicting terminal states, a changed business version, an incorrect task identifier, and two writers submitting concurrently. For each, check observation count, displayed state, result files, and whether a creation request was sent by mistake. Use isolated records for tests; do not write simulated successes into the real task ledger. Passing means more than a clean-looking page: no task is recreated and no anomalous evidence is lost.
Deliver integration work and asset production separately
When producing assets at https://flux-art.net/en, the business team still needs to review image content; a successful task state does not replace asset quality review. Engineering delivers observation-field documentation, transition rules, concurrent-write tests, and an exception queue. Operations delivers the approved asset for the current task. Linking the two records by task_id and business version helps distinguish a network write-back issue from an actual delivery issue, instead of masking a system error by generating another image.