-
-
Notifications
You must be signed in to change notification settings - Fork 444
Open
Labels
spec-gloasIssues targeting the Glamsterdam spec versionIssues targeting the Glamsterdam spec version
Description
Context
In persistPayloadEnvelopeInput(), a DB write failure causes the in-memory PayloadEnvelopeInput to be pruned via .finally(), losing data from both DB and memory with no recovery path. This is the same pattern as persistBlockInput().
Current behavior
await writePayloadEnvelopeInputToDb.call(this, payloadInput)
.catch((e) => {
this.logger.error("Error persisting payload envelope in hot db", {...}, e);
})
.finally(() => {
this.seenPayloadEnvelopeInput.prune(payloadInput.blockRootHex);
// ...
});On a transient DB error (disk full, I/O timeout), .catch() logs the error but .finally() still prunes the in-memory data. The envelope is now gone from both DB and memory β irrecoverable.
Proposed fix
- Only prune on success (move prune from
.finally()to.then()) - Add a retry mechanism for transient failures (exponential backoff, bounded retries)
- Apply the same fix to
persistBlockInput()which has the identical pattern
References
- PR feat: add gloas execution payload envelope import pipelineΒ #8962 β
writePayloadEnvelopeInputToDb.ts(review thread) - Same pattern exists in
persistBlockInput()(noted by @twoeths)
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
spec-gloasIssues targeting the Glamsterdam spec versionIssues targeting the Glamsterdam spec version