Skip to content

fix(factory-reset): parse the omnect-device-service result shape of feature version 4 - #126

Draft
JanZachmann wants to merge 1 commit into
omnect:mainfrom
JanZachmann:fix/ods-factory-reset-v4
Draft

fix(factory-reset): parse the omnect-device-service result shape of feature version 4#126
JanZachmann wants to merge 1 commit into
omnect:mainfrom
JanZachmann:fix/ods-factory-reset-v4

Conversation

@JanZachmann

Copy link
Copy Markdown
Contributor

Summary

Adapts the factory-reset result wire types to the shape omnect-device-service publishes on FactoryResetV1 with factory_reset feature version 4 (omnect/omnect-device-service#207): status is a u32 with the codes success, invalid, error, configError and warning plus a catch-all, error and context arrive as null when nothing went wrong, and the new data_wiped flag tells whether the destructive phase had already started. Raises the required omnect-device-service version to >=0.46.0.

The domain status enum keeps two distinct non-result variants. Unknown stays the default and means "no result received yet", which is what keeps the result modal silent. Unrecognized is where the catch-all lands, so a status code a future omnect-device-service invents still reaches the user. Mapping the catch-all onto Unknown would have swallowed such a result instead.

data_wiped is shown only on a non-success result. There it changes what the user has to do, because the device may sit in a half-wiped state and needs another reset to reach a defined one. On success it carries no action.

warning counts as success in the UI: the reset completed, a partition just needed a second format attempt.

Reason

Closes #125. Once omnect/omnect-device-service#207 merges, error is null on a successful reset while omnect-ui still requires a String, so every factory-reset result fails to deserialize and the UI shows a parse error instead of the result — including for a completely normal successful reset. The status codes were renamed and extended in the same change, so the old repr(u8) enum with four variants can no longer name what the device reports.

This is a draft because the >=0.46.0 floor is not confirmed yet. omnect/omnect-device-service#207 is still open and its branch says 0.44.2 while omnect-device-service main is already at 0.45.2, so the release that actually ships feature version 4 is not known. The constant carries a TODO marker naming that condition; it has to be replaced with the real tag before merge.

…eature version 4

Adapt the factory-reset result wire types to the shape omnect-device-service
publishes on FactoryResetV1 with factory_reset feature version 4:

- status is a u32 with the codes success, invalid, error, configError and
  warning, plus a catch-all so a future code parses instead of failing the
  whole update
- error and context arrive as null when nothing went wrong
- data_wiped tells whether the destructive phase had already started

Raise the required omnect-device-service version to 0.46.0.

Signed-off-by: Jan Zachmann 50990105+JanZachmann@users.noreply.github.com
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Adapt factory-reset result parsing to the new omnect-device-service result shape (feature version 4)

1 participant