AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
High 71 Bitcoin

Reset LSPS5 `persistence_in_flight` counter on persist errors

Public commit record

What the developer wrote

Authored by Elias Rohrer

73/100 · Adequate
Reset LSPS5 `persistence_in_flight` counter on persist errors

`LSPS5ServiceHandler::persist` incremented `persistence_in_flight` at
the top as a single-runner gate, but only decremented it on the
success path: each interior `?` on a `kv_store` future propagated the
error out of the function while leaving the counter at >= 1. After
one transient I/O failure (disk full, brief unavailability of a
remote `KVStore`, EPERM, etc.) every subsequent `persist()` call hit
the `fetch_add > 0` short-circuit and silently returned `Ok(false)`.

The in-memory `needs_persist` flags then continued to grow without
ever reaching disk, so webhook state, removals, and notification
cooldowns were lost on the next process restart — including the
spec-mandated webhook retention/pruning state — without any error
surfaced to the operator. The counter is monotonic, so recovery
required a process restart.

Adopt the LSPS1 / LSPS2 pattern: split the body into an inner
`do_persist` and an outer `persist` that unconditionally clears the
counter via `store(0)` after the call returns, regardless of
outcome. A failed write now still propagates `Err`, but the next
`persist()` attempt actually retries the write instead of no-op'ing.

Co-Authored-By: HAL 9000
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

A bug in the LSPS5 (webhook) service meant that one failed disk/storage write could permanently disable all future saves of webhook state until the program was restarted. The code used a counter to make sure only one save runs at a time, but it only reset that counter on success. After any error, every later save call silently did nothing and returned success, so operators saw no errors while important data was lost. The patch resets the counter even when writes fail, so retries happen normally.

Recommended action

Apply the patch. Ensure any deployments running LSPS5 webhook services are updated, because a single transient KV store failure can silently stop persistence until restart. Monitor for prior occurrences of Ok(false) persist returns paired with webhook state loss after restarts.

Security signals we found

01

Single-runner gate counter not reset on error path, causing permanent silent failure of persistence

02

In-memory state (webhooks, removals, notification cooldowns, spec-mandated retention/pruning state) lost on process restart

03

No error surfaced to operator after the first transient I/O failure

04

Recovery required process restart because counter is monotonic

05

Regression test added to verify persistence retries after KV store failure

Risk score

Why this scored 71/100

Our methodology →
Potential impact 22/30
Exploitability 12/25
Stealth signal 13/15
Affected reach 10/15
Confidence 9/10
Evidence quality 5/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.