Flux ArtIdentify the latest selection first
When building your own asset selector for Flux Art images, selecting A and then B but ultimately seeing A does not necessarily indicate an upload failure. Reading, decoding, and committing to the interface are separate stages, and the task started first may finish last. This article covers result ownership in a custom preview tool. It neither evaluates generated image quality nor claims that the platform has this fault. Acceptance means the thumbnail, filename, current asset ID, and export source all point to the version the user most recently accepted, not merely that an image appears.
Log selection and completion separately
Assign an increasing sequence number to each valid selection, recording the file identity, start time, completion state, and whether the result was ultimately allowed to commit. Filenames can match and cannot identify a version on their own. Logs should distinguish 'B selected,' 'A decoded,' 'A discarded,' and 'B committed' so that out-of-order completion is visible. Do not log the entire image or the user's full local path. A single generic completion message cannot show which selection finished, much less establish that the problem has been fixed.
Decoding completion does not grant UI ownership
The Promise returned by HTMLImageElement.decode can wait for decoding before displaying an image. Request failures, data problems, or source changes during decoding may cause rejection. It handles image readiness; it does not decide whether the result still belongs to the current selection. Give each task a separate candidate image and a captured selection number. After asynchronous work ends, compare that number with the current one again before updating the interface. The table below separates these stages so that completion order is not mistaken for user-intent order.
| Event order | What should commit | What to retain |
|---|---|---|
| A starts, then B starts | Do not infer a winner from start order | Both selection numbers |
| B finishes first | Commit B only if it is still current | B's commit record |
| A finishes later | Discard stale A | Reason for discarding A |
| A stale task fails | Do not overwrite current success | Selection number owning the error |
| The current task fails | Mark that it has not taken over | Recoverable previous state |
| A task ends after closure | Do not write to the closed interface | Closure and cleanup records |
Let only the current task commit the whole display
If the number still matches, update the image, name, asset ID, and export reference together in one commit. If it is stale, clean up only that candidate's resources and leave current state unchanged. Do not change the filename to B and then let A's image callback overwrite the picture. To show loading progress, you can label B as preparing while keeping the previously confirmed A visible, clearly identifying A as something other than the completed new selection. Keeping the old preview is a product choice, provided that labels and actions do not mislead.
Check ownership of errors too
If A's failure arrives after B succeeds, it should not turn B's interface into an error page. Error callbacks also need a task-identity check; stale errors belong only in diagnostic records. When the current B fails, clearly mark that B has not taken over, rather than saving the old image as B. Canceling or changing selection does not necessarily interrupt underlying decoding. Keep the pre-commit check even if you add cancellation: ignoring stale results and stopping computation are different operations, and implementing the latter does not replace the former.
Create a repeatable out-of-order example
Suppose a test tool deliberately delays A's preparation, lets B finish first, and then allows A to finish. This is a hypothetical test, not a real platform speed measurement. The final display and exported file should still come from B. Next test A succeeding while B fails, A failing while B succeeds, and three successive selections with the same filename but different contents. Retain the order of every start, completion, commit, and discard. A few rapid clicks under normal network conditions may never trigger a race, so 'not observed yet' cannot replace controlled out-of-order testing.
Do not let cleanup damage the new task
A stale candidate may hold its own object URL, image object, or other temporary resource. Cleanup must carry that candidate's identity; it must not simply release whatever a global variable now contains after another task has overwritten it. Shared resources need separate, explicit ownership management. When closing the panel, invalidate the current selection before arranging candidate shutdown so that a late callback cannot write to an unmounted interface. The committed current image still supports user actions and must not be released merely because another task became stale.
Finish verification with the exported result
An acceptance record should capture the current selection ID, visible preview, and a content summary of the exported file; compare independently calculated file hashes where appropriate. If the tool re-encodes images, do not require exported bytes to equal the original. Check the declared export version and its content instead. Pending encoding work also needs a selection identity. Mark untested browser behavior during closing or rapid switching as unknown and retain its limitations. A correct frontend display does not prove that every later business record is correct.
References and integration boundaries
Technical references checked on November 9, 2026: the image decoding API is documented at https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode . Selection numbering and an atomic-style UI handoff are engineering recommendations in this article, not capabilities supplied automatically by that API. Flux Art results can be used commercially. Third-party input rights and product authenticity require separate verification. For business integration after obtaining images, see https://flux-art.net/en/openapi ; test concurrency in your custom previewer separately, and do not present this example as a measurement of platform upload or generation speed.