fix(factory_reset): adapt result parsing to omnect-os-init JSON contract - #207
Open
JanZachmann wants to merge 3 commits into
Open
fix(factory_reset): adapt result parsing to omnect-os-init JSON contract#207JanZachmann wants to merge 3 commits into
JanZachmann wants to merge 3 commits into
Conversation
omnect-os-init writes the factory-reset result with key "factory_reset", status codes 0..=4 and optional error/context/paths fields. The old parser expected key "factory-reset" and required error/paths, so the result was never reported. - read key "factory_reset" - add status 4 (warning: reset ok, but a partition needed a second mkfs) - error, context and paths are optional with defaults - a future unknown status code parses as Unknown instead of failing ODS startup; the raw result is logged - status is u32 to match the omnect-os-init serialization - bump feature version to 4 because the reported result shape changed Signed-off-by: Jan Zachmann <50990105+JanZachmann@users.noreply.github.com>
Twin reports are merge patches: a key omitted from a new result keeps the value of a previous one. Report error and context as null instead of omitting them, so a successful reset clears the error of an earlier failed one. - report data_wiped: on error it distinguishes a safe abort from a failure after data was already wiped - rename status variants to the omnect-os-init names (wire format unchanged; the old names described the codes wrongly in logs) - align warning testfile with real omnect-os-init output (warning carries a context note, no error) - test explicit "factory_reset": null and that FactoryReset::new() succeeds with an unknown status code - document the result fields in the README Signed-off-by: Jan Zachmann <50990105+JanZachmann@users.noreply.github.com>
Signed-off-by: Jan Zachmann <50990105+JanZachmann@users.noreply.github.com>
Contributor
Author
|
FYI @mlilien |
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.
Closes #205
Summary
Adapt the factory-reset result parsing to the JSON that omnect-os-init writes to
/run/omnect-device-service/omnect-os-initramfs.json:factory_reset(wasfactory-reset)4(warning: reset ok, but a partition needed a secondmkfs)error,contextandpathsare optional with defaultsUnknown(reported asu32::MAX) instead of failing ODS startup; the raw result is logged as warningu32to match the omnect-os-init serialization (serialize_u32), so even a code > 255 cannot break startupdata_wiped: on error it distinguishes a safe abort from a failure after data was already wipederrorandcontextasnullinstead of omitting them: twin reports are merge patches, so an omitted key would keep the value of a previous resultReason
The parser and the omnect-os-init contract did not match, so the factory-reset result never reached the twin. After fixing only the key, a
status: 4or a missingerror/pathswould have failedFactoryReset::new()and with it ODS startup. See #205 for the full mismatch table.Follow-up
omnect-ui deserializes the published result with a required
errorfield and status0..=3only, so it cannot parse the new shape (including the normal successful reset): omnect/omnect-ui#125