Fix deserialization of YAML-tagged values in job log extra fields#32
Merged
Conversation
Copilot
AI
changed the title
[WIP] Fix fails to parse extra data in results message
Fix deserialization of YAML-tagged values in job log extra fields
Jun 23, 2026
There was a problem hiding this comment.
Pull request overview
This PR fixes a deserialization failure in JobLogEntry.msg when LAVA emits YAML-tagged scalars (e.g. ! "188250") inside the extra map of results log entries by avoiding serde’s untagged-enum ContentVisitor path and routing deserialization through serde_norway::Value first.
Changes:
- Replaced
JobLogMsg’s#[serde(untagged)]derivedDeserializewith a customDeserializeimpl that first deserializes intoserde_norway::Valueand then dispatches by value type. - Added regression/unit tests covering tagged values in
extra, plus string and sequencemsgforms.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
sjoerdsimons
force-pushed
the
copilot/fix-extra-data-parsing
branch
from
204025c to
ffbe777
Compare
sjoerdsimons
approved these changes
Jun 23, 2026
sjoerdsimons
force-pushed
the
copilot/fix-extra-data-parsing
branch
from
ffbe777 to
1cd8905
Compare
LAVA sometimes emits tagged YAML values (e.g. `! "188250"`) in the `extra` field of results log entries. The previous `#[serde(untagged)]` on `JobLogMsg` caused serde's internal ContentVisitor to be used for buffering, and that visitor explicitly rejects `visit_enum` calls with: "untagged and internally tagged enums do not support enum input" Fix this by replacing the derived untagged Deserialize with a custom implementation that first deserializes the `msg` field as a `serde_norway::Value` (which fully supports tagged YAML values), then dispatches to the correct JobLogMsg variant based on the value type. Closes: #31
sjoerdsimons
force-pushed
the
copilot/fix-extra-data-parsing
branch
from
1cd8905 to
733dd27
Compare
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.
LAVA occasionally emits bare YAML tags (e.g.
! "188250") inside theextramap of results log entries. This caused a hard parse failure becauseJobLogMsgused#[serde(untagged)], which routes deserialization through serde's internalContentVisitor— and that visitor explicitly rejectsvisit_enumcalls with:serde_norway represents YAML-tagged values via
visit_enum, so any tagged scalar inextrawould crash the parser.Changes
joblog.rs—JobLogMsg: Replace#[serde(untagged)]+ derivedDeserializewith a hand-written impl that deserializesmsgfirst intoserde_norway::Value(which has a properTaggedvariant and handlesvisit_enumcorrectly), then dispatches by value type:Value::String→MsgValue::Sequence→MsgsValue::Mapping→from_value::<JobResult>(...)This means tagged values like
! "188250"survive intoextraasValue::Tagged(...)rather than causing a parse error.Example input that previously failed: