anton-vinogradov opened a new pull request, #13435: URL: https://github.com/apache/ignite/pull/13435
[IGNITE-28271](https://issues.apache.org/jira/browse/IGNITE-28271) `GridJobExecuteResponse` carried three hand-written pairs of "object + bytes" — the job exception, the job result and the job attributes — served by `marshallUserData` and `unmarshallUserData`, which the callers invoked with an explicit `Marshaller`. All three become normal `@Marshalled` fields, and the message becomes a `DeferredUnmarshalMessage`, the way `GridJobExecuteRequest` works since IGNITE-28356. ### Not through `ErrorMessage`, and this is the point The summary of the ticket asks to send the exception as an `ErrorMessage`. That is what breaks it, and it is very likely why the earlier attempt (IGNITE-26817) was reverted in IGNITE-26890. `ErrorMessage` never fails: when it cannot write or read its payload it substitutes a wrapper. `GridP2PComputeExceptionTest` pins the opposite contract — an exception that cannot be deserialized must reach the caller as a `BinaryObjectException`, not as a wrapped `IgniteException`. With `ErrorMessage` two of its four tests fail. A plain `@Marshalled("gridExBytes") IgniteException gridEx` reaches the goal of the ticket — no hand-written marshalling — while the generated code does the same `U.unmarshal` the old code did, so the failure semantics are untouched. Worth noting for the record: the revert was not about the peer-deployment class loader. The two tests that cover a peer-deployed exception class pass here, because the message is deferred. ### Where the failure policy went `marshallUserData` was not only marshalling: a payload that could not be serialized was turned into an exception for the caller, so a job never failed silently. That policy now lives in one place, `GridJobExecuteResponse.marshalled(...)`, which the two senders call instead: 1. marshal the response; if it works, nothing else happens; 2. if it fails, build a response carrying only the error — the job exception when there is one, otherwise the marshalling failure — and marshal that; 3. if that fails too, the exception itself is the problem, so substitute a plain `IgniteException` with the same `Failed to serialize job exception` text the old code used. The old code also chained a second failure onto the first with `addSuppressed` when both the result and the attributes were broken. That is gone: the first failure now ends the marshalling. The message still names the node, the session and the job. `res` and `jobAttrs` get `@GridToStringExclude`, as in `GridJobExecuteRequest` — the old code erased the objects after marshalling, the generated code keeps them, and without the exclusion `toString()` would print a user payload into the log. The `marsh` field of `GridJobWorker` and `GridTaskWorker` is unused after this and is removed. ### Wire format This changes it: the three payloads keep their `@Order` slots and their bytes, but the message is no longer unmarshalled by the generic inbound pass. It has to be merged before 2.19 is released. ### Checks * `GridP2PComputeExceptionTest` - 4 of 4. This is the suite the earlier attempt was reverted over; * `GridP2PTimeoutSelfTest` - 8 of 8, `GridP2PMissedResourceCacheSizeSelfTest` - 8 of 8; * `GridJobStealingSelfTest` - 11, `GridTaskFailoverSelfTest`, `IgniteCoreMessagesSerializationTest` - green; * checkstyle with `-Pcheckstyle` - no violations. 🤖 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]
