Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
65655: changefeedccl: unskip TestChangefeedDataTTL r=miretskiy a=stevendanna Much has changed since this test was originally written and since it was originally skipped. Namely, moving to rangefeeds as the underlying driver of changefeeds and the addition of protected timestamps during backfills. When I uncomment the skip on master, we see 1) The `enterprise` test suite always timing out 2) The `sinkless` test suite almost always passing While the sinkless test suite passed, it wasn't passing in the way some of the comments in the test expected. As written, I believe this test would observe the expected failure only if the GC had occurred before the first call to dist.RangeFeed. In the sinkless case, we were typically blocking the Emit of the first message sent via the backfill. Since the backfill happens before the Rangefeed is started, this meant that the first call to dist.RangeFeed happened after the GC and thus the expected errors was returned when we requested a rangefeed starting before the GC. From my reading of this code, that was technically racy and wasn't guaranteed, but on my laptop, the test always passed. Note that this doesn't match the in-code comments which expected that the feed should see at least one of the updates before failing. In the enterprise case, we created a protected timestamp before starting the backfill. This protected timestamp renders our attempt to force the GC useless, meaning that when we start the RangeFeed, our desired timestamp is still available and no error is emitted. This PR - Removes the enterprise test case - Modifies the sinkless test case to more explicitly test the sequence of events it was testing before. - Makes it a test failure if all row updates are seen by the test feed, meaning we don't have to wait for a timeout to fail if this test is still racy somehow. Testing the right behaviour of rangefeeds when they fall behind the GC TTL seems like a test that better belongs in the rangefeed code if we need such a test. Fixes #37154 Release note: None Co-authored-by: Steven Danna <[email protected]>
- Loading branch information