Handle FxA capabilities and re-sending data better
bendk opened this issue · 1 comments
bendk commented
We should fix some issues with our FxA capabitily handling
- We store the last-sent capabilities as a list with the empty list meaning that we need to re-register capabilities with the server yet. This means we don't distinguish between the case of a client with no capabilities and one with capabilities that haven't been registered, which will result in unneeded API calls. We should covert
StateV2.device_capabilites
to anOption<Vec<>>
to distinguish the two. I think this may require a 1 time migration that converts[]
toNone
, although if there are no clients in the wild that have 0 capabilities, maybe this isn't needed. - When we fail to send a device update request to the server, we arrange for the capabilities to be re-registered. However, the device update request may have other data that also needs to be re-sent as discussed in this comment. Maybe we should should using `device_capabilities' to indicate that we need to re-send data to the server and use a separate field for that that can have more details about exactly what needs to be re-uploaded.
┆Issue is synchronized with this Jira Task
mhammond commented
Moved to bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1866533
Change performed by the Move to Bugzilla add-on.