Investigate repeated mainnet publication stops during read-only preflight checks #2

New issue

Open

opened 2026-10-05 00:19:55 +00:00 by rhelwig · 1 comment

rhelwig commented

2026-10-05 00:19:55 +00:00

Owner

Evidence:

Final device journal: 16 attempts, all 16 confirmed, zero uncertain and zero rejected.
Independent proof-enabled Platform inspection: exact frozen release active, all metadata records match.
Last retained sanitized diagnostic: OPERATION_FAILED, stage checking, 12 recorded attempts, unresolved=false.
The current diagnostic does not identify which read failed, so network instability, a proof/query failure or another preflight condition is not yet established as the cause.

Investigation:

Add bounded, non-sensitive diagnostics that identify the failed read without recording keys or raw SDK payloads.
Reproduce transient mainnet reads and determine whether bounded retries of read-only preflight checks are appropriate.
Preserve expiry/nonce/owner/schema/credit checks, durable receipts and one-use approval.
Never automatically rebroadcast an uncertain transaction or weaken confirmation checks.
Cover any fix with failure-injection tests.

Deferred investigation is acceptable at the owner's request if there is no small, established fix. Live identities, transaction hashes, receipts and deployment records remain outside this public issue.

A mainnet release containing 16 operations required repeated Check again / fresh fee reviews before finishing. Stops occurred after 1, 4, 5, 6, 8 and 12 confirmed operations; a fee-review check also intermittently reported Could not check publishing. The release eventually reported Published and verified on mainnet. Evidence: - Final device journal: 16 attempts, all 16 confirmed, zero uncertain and zero rejected. - Independent proof-enabled Platform inspection: exact frozen release active, all metadata records match. - Last retained sanitized diagnostic: OPERATION_FAILED, stage checking, 12 recorded attempts, unresolved=false. - The current diagnostic does not identify which read failed, so network instability, a proof/query failure or another preflight condition is not yet established as the cause. Investigation: - Add bounded, non-sensitive diagnostics that identify the failed read without recording keys or raw SDK payloads. - Reproduce transient mainnet reads and determine whether bounded retries of read-only preflight checks are appropriate. - Preserve expiry/nonce/owner/schema/credit checks, durable receipts and one-use approval. - Never automatically rebroadcast an uncertain transaction or weaken confirmation checks. - Cover any fix with failure-injection tests. Deferred investigation is acceptable at the owner's request if there is no small, established fix. Live identities, transaction hashes, receipts and deployment records remain outside this public issue.

rhelwig commented

2026-10-05 00:34:40 +00:00

Author

Owner

Investigation remains deferred. An additional mainnet reader observation may be relevant: a newly switched public Stub failed its first cold-cache read, then fully loaded and verified the same release after a fresh connection. Both hosts ultimately verified all content hashes and reported healthy mainnet caches. This does not establish that the Stub and Auth failures share a cause. No automatic transaction retry or weakened confirmation logic was introduced.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

rhelwig/DecentSite#2

No description provided.

Rows
Columns