Bug report
TestProcessTableTriggerDispatcherSendsSignalResolvedWhenNoForwardRangeAndNotInCommitStage is brittle and can look flaky when the surrounding implementation changes.
Background
The test is intended to verify the table trigger dispatcher behavior when there is no forward range and the changefeed is not in the syncpoint commit stage. In that case, the dispatcher should send a signal resolved event without advancing past the current watermark.
Problem
The current test couples that behavior to two unrelated implementation details:
- It assumes the dispatcher is still unhandshaked, so the first message must be a
HandshakeEvent.
- It uses
time.Now().Add(...) to bypass the resolved-ts rate limit, which makes the setup depend on wall clock timing instead of deterministic state.
Because of that, the test is validating more than its name suggests, and it becomes fragile under benign changes to handshake timing or resolved-ts throttling.
Expected behavior
The test should only assert the behavior it is named after:
- a signal resolved event is emitted when there is no forward range
- the resolved watermark stays at the current value
nextSyncPoint is unchanged
Suggested fix
Make the test deterministic by:
- pre-marking the dispatcher as handshaked so handshake ordering is out of scope
- using a zero
lastSentResolvedTsTime to bypass the rate limit deterministically
- asserting only the emitted resolved event and the relevant watermark state
Bug report
TestProcessTableTriggerDispatcherSendsSignalResolvedWhenNoForwardRangeAndNotInCommitStageis brittle and can look flaky when the surrounding implementation changes.Background
The test is intended to verify the table trigger dispatcher behavior when there is no forward range and the changefeed is not in the syncpoint commit stage. In that case, the dispatcher should send a signal resolved event without advancing past the current watermark.
Problem
The current test couples that behavior to two unrelated implementation details:
HandshakeEvent.time.Now().Add(...)to bypass the resolved-ts rate limit, which makes the setup depend on wall clock timing instead of deterministic state.Because of that, the test is validating more than its name suggests, and it becomes fragile under benign changes to handshake timing or resolved-ts throttling.
Expected behavior
The test should only assert the behavior it is named after:
nextSyncPointis unchangedSuggested fix
Make the test deterministic by:
lastSentResolvedTsTimeto bypass the rate limit deterministically