stubbsta 95d0a8bdd8
Replace forceMerkleProofRefresh flag with invalidateMerkleProofCache
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>
2026-07-09 12:51:37 +02:00
..
2026-06-25 09:27:01 +02:00