DanielLeens commented on issue #11462: URL: https://github.com/apache/seatunnel/issues/11462#issuecomment-4997998333
Looked through the current `IMapFileData.compareTo()` implementation, and this appears to be a genuine bug in the file-based IMap WAL ordering path. The core issue is that the comparator never returns `0`. When two entries share the same timestamp, the current code violates the `Comparable` contract, which can break `Collections.sort(...)` and also make same-millisecond PUT/DELETE ordering undefined during deduplication. That means this is not only a potential `TimSort` crash; it can also affect correctness in the restore/read path when equal-timestamp records are replayed. There is not a clean config-level workaround for the contract violation itself. If you need to reduce exposure before a fix lands, using a non-file IMap storage backend would be safer where that is practical. This issue is worth keeping open for follow-up. We've labeled it as `help wanted` — contributions are very welcome. -- 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]
