dalelane commented on PR #307: URL: https://github.com/apache/flink-connector-kafka/pull/307#issuecomment-5604865122
I'm not sure this is about a timeout - although it says timeout in the error message "Timeout waiting for 100 records" the next bit of the error message in the [copyright update PR mentioned in Jira](https://github.com/apache/flink-connector-kafka/actions/runs/34200093784/job/102428596113) was "Found 150 records in topic SourceTopicIntegrityTest_sink-topic (expected: 100)" I just raised https://issues.apache.org/jira/browse/FLINK-40620 for this same test (_sorry! I did check for existing tickets when I started digging into this, but I think you must have created your issue while I was working on my approach to a fix_) because it tripped up [my PR](https://github.com/apache/flink-connector-kafka/pull/293) as well. I've come up with a different type of fix for this. (That's not to say that it might not also be sensible to flip it to an integration test for the reasons you describe, but I don't think that's what this error is saying is the issue.) I've tried adapting it so the test now runs each subscription mode twice (once with the sink set to at-least-once delivery and once to exactly-once, where previously it only ever ran at-least-once). In the at-least-once runs it asserts that no records were lost rather than insisting on an exact count, so these sorts of failures aren't a block. In the exactly-once run, it still asserts the exact count because that mode genuinely promises no duplicates -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
