mirror of
https://github.com/logos-messaging/logos-delivery.git
synced 2026-07-21 12:09:29 +00:00
855818f545
On a stale-merkle-proof rejection the kernel and REST layers no longer republish internally. They schedule a detached merkle proof refresh and fail fast with a distinguishable, retry-worthy error, leaving the retry decision to the caller. - add GroupManager.scheduleMerkleProofRefresh: drops the cached path and asyncSpawns the refetch (join-shielded, so a cancelled caller never cancels the shared refetch); base is a no-op. - v3 lightpush (node.lightpushPublish): on an RLN-related 420/504, call scheduleMerkleProofRefresh and return immediately, normalized to 504 OUT_OF_RLN_PROOF with RlnProofRefreshScheduledMsg. The internal republish and its bounded timeout are gone. - send service: lightpushPublishToAny now routes through node.lightpushPublish so every NextRoundRetry round regenerates the proof against the current cache; the existing OUT_OF_RLN_PROOF -> NextRoundRetry mapping is the retry. - REST lightpush: pass the 504 through unchanged (no internal retry). - REST relay: attachRlnProofValidateWithRetry -> attachRlnProofAndValidate; validate once, on RLN-invalid schedule the refresh and return 503 with the marker instead of regenerating and revalidating in-request. - rename RlnRefreshRetryTimeout -> RlnMerkleProofRefreshTimeout; it now bounds only the legacy lightpush refresh, which keeps its one-shot internal retry (no wire error taxonomy to delegate to callers). Not touched: legacy lightpush retry behavior, the proof.nim attachRLNProof/checkAndGenerateRLNProof split, and the merkle path refetch/coalescing internals of ensureFreshMerkleProofPath. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>