Busy Flag Bound To Wrong Event

What goes wrong

A 'busy' or 'in progress' flag for one target is set or cleared on the wrong event — cleared before the operation is safe to repeat, or held until a long unrelated step finishes. A repeat in the gap duplicates the work; or unrelated actions stay blocked for the whole operation.

Example

The submitting flag is reset when the request is sent rather than when the server answers; a second click in that gap creates a duplicate payment.

Not to be confused with

The flag's key is right and only its lifetime is wrong — not one flag shared across independent targets (Key Omits A Dimension) and not a flag never cleared at all (Marker Outlives Its Operation).

Discovered by

@sks24git GitHub

Field notes · 7

@sks24git2026-10-27beat 1 review round

A "restore focus after remount" flag was armed on every edge gesture but cleared only when a remount really happened. A no-op gesture at the boundary left it armed, so a later remount stole keyboard focus.

Arm a one-shot flag only when the action it waits for really happens. Set on intent, cleared on effect, it leaks across every no-op.
Test the boundary where the action is a no-op.

@sks24git2026-10-17beat 1 review round

A status parser cleared its idle flag on only one of the several messages that mean work has started. When any other kind of work began, the system stayed in slow mode and started one job at a time.

List every message that means started, not just the common one. A missed case keeps the throttle on.
Test with one real sample per message type. The line you forgot fails fast.

@sks24git2026-10-16

A rewrite judged a worker alive only by its unfinished job row, but the row closes before the worker publishes. A second worker sees it closed mid-publish and starts a duplicate paid job.

Mark liveness by heartbeat, not by a row's end. A row can close while its owner still works.
Record the outcome before releasing the claim. Any gap lets a second worker in.

@sks24git2026-09-12

One in-flight guard sat behind a button rendered once per row. Archive one row, then another before the first settles: the guard refuses the second in silence — no request, no error, nothing disabled to see.

Key a guard by the row it protects, never by the page. One shared flag turns a neighbour's click into silence.
A guard that refuses must show it refused.

@sks24git2026-09-11beat 1 review round

A submit button took its in-flight lock before validation ran, so an invalid click flashed a busy spinner for a request that never left the browser. The test checked only the final state, after the lock had released.

Lock after the check that decides whether work starts. A guard taken first turns rejected input into fake progress.
Assert the transient, not the end state. A flicker passes a test that waits.

@sks24git2026-09-06beat 8 review rounds

A dialog rendered closed on every page, and its visibility effect cleared the pending attempt on first run. The retry that should survive navigation died the moment the sidebar mounted elsewhere.

Effects on closed components still run. Guard lifecycle resets on the transition you mean, not on every render of the prop.

@sks24git2026-09-06beat 18 review rounds

An abort cancelled a shared download but left its entry in the cache until the socket rejected. The next queued review woke in the same tick, joined the dead entry and failed with a stranger's error.

Abort and evict in the same statement. Between the cancel and the rejection there is a tick, and a FIFO wake-up lands in it.