linliu-code opened a new pull request, #19908: URL: https://github.com/apache/hudi/pull/19908
### Describe the issue this Pull Request addresses part of #19901, and the same family as #19899 ### Summary and Changelog `HoodieCreateRecordUtils` computed a record's ordering value only when `shouldCombine` was true. That flag answers whether the incoming batch needs de-duplicating, which is a different question from whether a record needs an ordering value: it is false for prepped Spark SQL writes, which emit one row per key, and for any upsert with `hoodie.combine.before.upsert` turned off. On the `HoodieAvroRecord` branch the record then served the payload's default ordering value, an `Integer`, rather than the ordering field's value. This computes the ordering value whenever the table's merge mode needs one. Deletes are deliberately excluded from the widened branch so their semantics do not change: `BufferedRecordMergerFactory.deltaMergeDeleteRecord` treats a delete carrying the default as commit time ordered, and giving it a real value would make a delete lose to a stored record with a higher ordering value. Deletes still get an ordering value when `shouldCombine` is true, as before. ### Impact On a table that orders by event time, an affected record's `Integer` default was compared against the base record's ordering value read from storage: a `ClassCastException` for any ordering column that is not an `int`, or, on an `int` column, the update silently discarded. Commit time ordered tables and delete semantics are unchanged. No public API change. ### Risk Level low The new branch is taken only when the table declares ordering fields, the merge mode is not `COMMIT_TIME_ORDERING`, and the record is not a delete, and it then performs the extraction the `shouldCombine` branch beside it already performed. `TestHoodieCreateRecordUtils` pins three cases, each proved by reverting: the event time case fails against master with `Unexpected type, expected: <java.lang.Long> but was: <java.lang.Integer>`; the delete case fails with `expected: <0> but was: <1757000000000>` when the exclusion is removed; the commit time case guards the branch that protects existing tables. ### Documentation Update None. No new config, no default value change, no user facing feature change. ### Contributor's checklist - [x] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [x] Enough context is provided in the sections above - [x] Adequate tests were added if applicable 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
