Tracked in Linear as QUI-830.
Problem
A node that mines valid solutions but lands zero extrinsics still reports is_mining=true, and its container stays Up. There is no signal that submissions are failing, so a total-submission-failure class is invisible to operators and monitoring until someone notices proofs_won has stopped moving.
This has now been independently corroborated by two separate field reports (#22, #26), in both cases as the part of the failure with the worst operator impact: the node looks healthy while silently missing every round.
Change
Add a last_successful_submission timestamp to /api/v1/status, set on each accepted submit_proof. A stale or null value while is_mining=true then directly indicates the submit path is broken.
Why this is independent of the submit-path fixes
The connection-swap and poisoned-pool defects (#26) are about why submits drop. This ticket adds the visibility that would have surfaced those failures on its own. The field is worth shipping regardless of how the submit path is fixed, and it guards against future regressions in that path.
Acceptance
/api/v1/status includes last_successful_submission (ISO timestamp, null before the first accepted submission).- The field updates only on an accepted submission, not on a mined-but-unsubmitted solution.
Tracked in Linear as QUI-830.
Problem
A node that mines valid solutions but lands zero extrinsics still reports
is_mining=true, and its container staysUp. There is no signal that submissions are failing, so a total-submission-failure class is invisible to operators and monitoring until someone noticesproofs_wonhas stopped moving.This has now been independently corroborated by two separate field reports (#22, #26), in both cases as the part of the failure with the worst operator impact: the node looks healthy while silently missing every round.
Change
Add a
last_successful_submissiontimestamp to/api/v1/status, set on each acceptedsubmit_proof. A stale or null value whileis_mining=truethen directly indicates the submit path is broken.Why this is independent of the submit-path fixes
The connection-swap and poisoned-pool defects (#26) are about why submits drop. This ticket adds the visibility that would have surfaced those failures on its own. The field is worth shipping regardless of how the submit path is fixed, and it guards against future regressions in that path.
Acceptance
/api/v1/statusincludeslast_successful_submission(ISO timestamp, null before the first accepted submission).