XianReallyHot-ZZH opened a new pull request, #13737: URL: https://github.com/apache/ignite/pull/13737
Ticket: IGNITE-29197 ## What changes `GridNearTxLocal.enlistWriteEntry()` builds the "cannot have update value in transaction after EntryProcessor is applied" error message with `CU.value(cacheKey, cacheCtx, false)`, which deserializes the key. If the key is a binary object built without a Java class, constructing the message itself throws `BinaryInvalidTypeException`, so the user sees a key deserialization failure instead of the actual reason the update was rejected. The message is now built through a `safeKeyValue()` helper: it first tries the current representation and falls back to `KeyCacheObject.toString()` if deserialization fails (for `BinaryObjectImpl` this prints the fields from binary metadata, no Java class required). For keys that deserialize normally the message text is unchanged. Note: the same `CU.value(...)` pattern exists in the "externally held" error message of the same method; left as is since it is a separate error path, happy to cover it in a follow-up if preferred. ## Testing New `IgniteBinaryTxPutAfterInvokeSelfTest` (modules/core, binary tests): single-node transactional cache, key built with `BinaryObjectBuilder` for a type without a Java class, `invoke()` followed by `put()` for that key inside a transaction. The test walks the exception chain to the root cause and asserts it carries "cannot have update value in transaction after EntryProcessor is applied". On the unfixed code the test fails with `BinaryInvalidTypeException: org.apache.ignite.nonexistent.TestKeyType` thrown from `GridNearTxLocal.enlistWriteEntry` — exactly the masking reported in the ticket. -- 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]
