Flux ArtStop accepting new work; that does not stop every task
When producing assets in batches through the Flux Art API, operations may pause a batch, change shifts, or perform maintenance. First stop new claims and submissions, then account for requests already sent; closing a process does not prove remote tasks were canceled. This is an integrator-side pause and handoff checklist. It assumes no extra platform cancellation interface and does not treat an unacknowledged request as unexecuted.
Write down the scope and cutoff first
Be explicit whether the pause covers one batch, one business version, or all creation entry points. Record when the pause takes effect, the batch identifier, and the responsible writer so another backend entry point cannot keep submitting. Hiding a button on a page does not ensure the server queue has stopped. Engineering should verify all relevant creation paths honor the pause marker while retaining query access and the ability to file necessary completed results; permissions and resource allocation for these actions should be specified in advance.
Group work by whether it crossed the submission boundary
Suppose a batch contains an unsent queue, processing tasks with task_id values, and requests sent without an acknowledgement. This is a hypothetical, not measured data, and the three groups cannot all be labeled paused and complete. The first can remain unsubmitted; the second should be checked under its existing task identity; the last should be listed separately as an unknown outcome and recovered from the original request record. The table below determines handoff actions; it does not guess remote task outcomes.
| Position at pause | Handoff classification | Permitted next action |
|---|---|---|
| Request is confirmed not sent | Unsubmitted, pending | Keep queued; wait for admission to resume |
| Task identifier has been received | Submitted, in flight | Query the same task and record its state |
| Request sent but no acknowledgement | Outcome unknown | Verify the original request; prohibit blind recreation |
| Remote task succeeded but file is not stored | Awaiting download or filing | Save and validate the file for the original task |
| File stored but not reviewed | Awaiting business review | Check the actual asset against the requirements |
| Still unfinished at cutoff | Continue with the next operator | Hand off identifier, evidence, and owner |
Handle the race window when stopping claims
A worker may have just picked up an item when the pause marker is written. Establish a controlled boundary between claiming and sending, and record which items have entered submission. Return items known not to have been sent to pending work; do not casually put items already sent, or not provably unsent, back in the ordinary queue. Otherwise the next operator may recreate the same business task. Implement the concurrency control in the custom queue and persistence layer.
Continue checking in-flight tasks; do not infer failure from elapsed time
For a task with a task_id, query its state using the current documentation; reaching a local maintenance window does not mean the remote task failed. Current Flux Art query fields and error handling are documented at https://flux-art.net/en/openapi/reference. Use backoff and a cutoff plan for polling rather than querying indefinitely to meet a shift change. If a task is still unfinished at handoff, preserve its known state, last check time, and next owner instead of marking it complete.
File delivery has a boundary after success
Remote success, successful file download, and accepted business asset are separate records. For a task that succeeded before shutdown but whose file is not reliably stored, record the task identifier, result source, and next download action; hand stored but unreviewed assets to operations for inspection. Do not hand over only a green task list. Validate the actual saved content; the existence of a temporary link does not mean a durable archive exists.
Preserve original request identity for unknown outcomes
If a request may have reached the remote service but its acknowledgement was lost, keep the original request identifier, idempotency key, parameter summary, and last execution step in the handoff; do not expose API keys. The next operator verifies it first, then recovers the same request according to the documentation rather than creating a new request identity because of a pause or shift change. If reliable verification is not possible, leave the outcome unknown. A traceable exception queue is safer than marking it failed and automatically retrying.
Give the next operator a verifiable checklist
The handoff package should include batch scope, evidence of the pause, counts in each group, identifiers for every unresolved item, locations of stored files, and the next action. The recipient should verify that counts cover the original batch and spot-check that no item appears in both unsubmitted and complete groups. Before accepting new work, confirm that the old writer no longer has formal write authority so two shifts do not act at once; saying in chat that someone logged off is not execution evidence.
The drill should prevent duplicates and missing items
In an isolated environment, test a pause racing with a claim, a network break after sending, a query that remains non-terminal, an interrupted download, and recovery by a new shift. Passing means every business item has a clear owner, unknown items remain explicit, and no task is created twice. The Flux Art entry point at https://flux-art.net/en and the integrator's queue control have distinct responsibilities; people still need to review asset quality, and a pause drill does not replace product-information and final-delivery review.