IGNITE-28271 Use the generated marshalling for GridJobExecuteResponse - #13435
Merged
Conversation
anton-vinogradov
force-pushed
the
ignite-28271
branch
2 times, most recently
from
August 4, 2026 22:02
e90485e to
fe1eab9
Compare
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
anton-vinogradov
force-pushed
the
ignite-28271
branch
from
August 4, 2026 22:37
fe1eab9 to
c11ea39
Compare
Contributor
Author
|
/runall 🚀 RunAll queued — build 9254157 · live progress & verdict: Ignite PR Checker. The verdict lands here when the run finishes. |
Contributor
Author
|
Ignite PR Checker verdict · RunAll build 9254157 · 147 suites ran, 0 reused ✅ No blockers — nothing in this run looks caused by this PR. 56 pre-existing/flaky tests filtered out. ♻️ Settled after 1 auto re-run wave(s): #1 — 2 blocker suite(s). |
wernerdv
approved these changes
Aug 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
IGNITE-28271
GridJobExecuteResponsecarried three hand-written pairs of "object + bytes" — the job exception, the job result and the job attributes — served bymarshallUserDataandunmarshallUserData, which the callers invoked with an explicitMarshaller. All three become normal@Marshalledfields, and the message becomes aDeferredUnmarshalMessage, the wayGridJobExecuteRequestworks since IGNITE-28356.Not through
ErrorMessage, and this is the pointThe 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.ErrorMessagenever fails: when it cannot write or read its payload it substitutes a wrapper.GridP2PComputeExceptionTestpins the opposite contract — an exception that cannot be deserialized must reach the caller as aBinaryObjectException, not as a wrappedIgniteException. WithErrorMessagetwo of its four tests fail.A plain
@Marshalled("gridExBytes") IgniteException gridExreaches the goal of the ticket — no hand-written marshalling — while the generated code does the sameU.unmarshalthe 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
marshallUserDatawas 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 stays, in the same place and the same shape — before the send, one message going out. Only the marshalling under it is the generated one now.GridJobProcessorbuilds a response that carries nothing but the exception, so there is only one thing that can fail there:GridJobWorkeralso carries the job result and the job attributes, so it drops the payload first and keeps the job exception — a broken result should not hide why the job actually failed — and only substitutes the exception when that too cannot be written. This is whatwrapSerializationErrordid.The message keeps one pure method for this,
withError(IgniteException), which copies the identity fields and drops the payload. No kernal context, no logger, no marshalling on the message any more.Pre-marshalling does not double the work: the generated code writes a
@Marshalledfield only when its companion is still empty (if (obj != null && bytes == null)), so the later pass over theGridIoMessagewrapper finds nothing to do. The old code relied on the same thing.One thing is not preserved: a second failure is no longer chained onto the first with
addSuppressedwhen both the result and the attributes are broken.resandjobAttrsget@GridToStringExclude, as inGridJobExecuteRequest— the old code erased the objects after marshalling, the generated code keeps them, and without the exclusiontoString()would print a user payload into the log.The
marshfield ofGridJobWorkerandGridTaskWorkeris unused after this and is removed.Wire format
This changes it: the three payloads keep their
@Orderslots 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;-Pcheckstyle- no violations.🤖 Generated with Claude Code