Flux ArtA live process does not necessarily still have write authority
In a batch system integrated with Flux Art, a worker may resume after a pause and still hold an old task to write to the ledger. If its lease has expired and another process has taken over, the old process cannot overwrite the record just because it has not exited. The integrator implements the lease and write generation; these are not new platform features. The risk is not two windows open at once, but an executor that lost ownership still committing data.
Keep the lease, generation, and business task distinct
A lease answers who may work now and for how long; a write generation distinguishes executors that acquired ownership in sequence; task_id identifies the remote task. Do not collapse all three into one string. On takeover, a reliable coordination or storage mechanism should issue a new increasing generation and persist the current owner. A random lock token can identify an owner but does not automatically establish takeover order; an increasing value also needs a reliable way to generate and persist it.
Test a stale write after a pause
Suppose A holds generation seven and pauses until its lease expires; B lawfully obtains generation eight and updates the local record; A then wakes and submits a result with generation seven. This is a fault-injection scenario, not a measured result. The storage endpoint should reject A's stale write and preserve evidence of the rejection. Do not let A overwrite first and rely on B to repair it later, or treat “A usually exits in time” as a concurrency guarantee.
| Failure input | What to reject or stop | Evidence to verify |
|---|---|---|
| A write arrives with an old generation | Reject overwriting the current record | Storage-side conditional update result |
| Lease renewal fails | Stop claiming tasks and making new submissions | Current ownership and failure time |
| Two takeovers compete | Accept only the lawful new owner | Coordination record and sole valid generation |
| Old process previously sent a creation request | Prohibit blind recreation | Request record, idempotency key, and task query |
| Generation record rolls back or is tampered with | Reject resuming formal writes | Persisted generation and trusted validation record |
| Remote outcome remains unknown | Keep unresolved; do not mark complete | Independent check result and assigned owner |
Check authority where the write actually commits
Checking a lock once when a process starts cannot protect a long network wait that follows. The final write must validate current ownership, generation, and any required lease conditions at the storage endpoint in the same atomic operation or transaction, then decide whether to accept it. If the generation is checked on the client and an unconditional write follows, ownership can change between the check and write. Without valid authority, reject the formal change rather than allowing an unknown state by default.
Stop new work when lease renewal fails
If renewal fails or ownership is uncertain, the old process should stop claiming new tasks and making new submissions, and leave unfinished work for recovery. Extending a local timer, continuing a loop, or checking only a process ID does not prove valid authority. Process IDs can be reused, and machine time is not the sole basis. Design the lease mechanism for the semantics of the chosen database or coordination service; do not assemble a simple substitute without atomicity.
Local fencing cannot block an external request already sent
A write generation protects local resources that validate it, but it cannot retract a creation request already sent remotely. The new owner still needs to check existing task_id values, request records, and unknown outcomes. Follow https://flux-art.net/en/openapi/reference for Flux Art creation-request idempotency constraints; when recovering the same request, reuse the corresponding idempotency key as documented instead of inventing a new business request merely because the worker changed.
Take over recovery with evidence
A takeover record should include the old owner, old generation, reason for expiry, new generation, takeover time, and unresolved steps. If a request may have been sent but its acknowledgement was lost, verify it independently; absence of local success does not mean the remote action did not happen. Keep items that cannot be verified unknown and prevent automatic repeated side effects. Recovery can advance steps known to be safe while keeping unknown steps in a separate queue; there is no need to fabricate completion.
Test storage rejection, not just lock acquisition
Isolated tests should cover an old process resuming after a pause, a tampered generation, failed lease validation, two competing takeovers, a generation that must not roll back after restart, and an unknown result for an existing external request. Assert that stale writes do not overwrite stored content, creation is not duplicated, and rejection reasons are traceable. Killing the old process is only a supplementary action, not the sole safeguard; before production integration, also validate real storage and coordinator failure behavior.
State clearly which capabilities are local and which are product capabilities
Redis's distributed-lock documentation at https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/ advises considering fencing tokens for long-running work; it supports this design direction but does not mean any lock implementation is inherently safe. Flux Art's entry point at https://flux-art.net/en can be used for asset work, while the integrator remains responsible for scheduling, persistence, and handoff. At delivery, specify which resources validate generations and which external side effects require separate checks; do not present a passing test double as production adoption.