mirror of
https://github.com/logos-messaging/logos-delivery.git
synced 2026-07-22 12:39:30 +00:00
The forceMerkleProofRefresh bool was threaded through five procs (checkAndGenerateRLNProof → generateRLNProof → generateProof base + on-chain → ensureFreshMerkleProofPath) purely so a caller could ask the merkle path to be refetched from chain on a stale-RLN retry. Reading any one of those signatures required a mental stack trace back up to the retry caller to know what "force" meant. Flip the contract: expose invalidateMerkleProofCache on the group manager; callers invoke it on the retry path to empty the cache, and the normal proof-gen flow then sees an empty cache and refetches on its own. No flag crosses procs. Removed forceMerkleProofRefresh from: - group_manager_base.generateProof (+ on_chain override) - ensureFreshMerkleProofPath (its `force` param) - generateRLNProof Renamed on checkAndGenerateRLNProof: forceMerkleProofRefresh → regenerate. It now controls one thing — bypassing the "message already has a proof" short-circuit — and never propagates downstream. Callers pair it with invalidateMerkleProofCache when they need the refetch semantics too. Retry callers updated in lockstep: generateRLNProofWithRootRefresh, REST attachRlnProofValidateWithRetry, and both legacy + modern lightpush retry paths now call groupManager.invalidateMerkleProofCache() before regenerating. The primitive test in test_wakunode_lightpush.nim now exercises the pair directly, and the onchain ensureFreshMerkleProofPath test is rewritten to exercise invalidate → ensureFresh as one flow (retiring its `force = true` variant). Pure refactor; behavior unchanged. Verified against: tests/waku_rln_relay/test_rln_group_manager_onchain.nim (29/29) tests/wakunode_rest/test_rest_relay.nim (13/13) tests/waku_rln_relay/test_wakunode_rln_relay.nim (5/5, 1 skip) tests/node/test_wakunode_lightpush.nim (11/11) tests/node/test_wakunode_legacy_lightpush.nim (9/9) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>