fix(logpoller): replay lower boundary revalidation

[jadepark-dev]

No description provided.

[Copilot]

Pull request overview

Updates TON logpoller replay handling to revalidate the replay lower boundary (the stored prevBlock, i.e., fromBlock-1) during override application so replays are rejected if that boundary was pruned after the original Replay() request.

Changes:

• Revalidate fromBlock-1 (or fromBlock when fromBlock==1) in applyReplayOverride() instead of revalidating fromBlock.
• Adjust existing replay override tests to match the new validation target (prevBlock).
• Add a new test case for the “prevBlock pruned between request and override” scenario.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
pkg/logpoller/replay.go	Changes replay override revalidation to validate prevBlock (lower boundary) to better handle pruning between request and override.
pkg/logpoller/replay_test.go	Updates comments/expectations for new validation behavior and adds a new rejection-path test.

Comments suppressed due to low confidence (1)

pkg/logpoller/replay.go:147

• applyReplayOverride clears the replay state on validation failure after releasing the replay mutex. Since Replay() can be called concurrently while this validation is in-flight (and keeps status Pending), a newer replay request can be overwritten by clearReplayRequest(). Consider re-checking that the in-memory replay request still matches the validated fromBlock (and/or a request ID) before clearing, or downgrade status back to Requested when the request has changed so the newer request is not lost.

	_, err := lp.lookupRequestedReplayBlock(ctx, blockToValidate, currentMasterchainBlock)
	if err != nil {
		lp.lggr.Warnw("replay rejected", "error", err, "fromBlock", fromBlock)
		lp.clearReplayRequest()
		return blockRange, 0

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.