non-blocking: this technically doesn't actually conform to RSH8a1, which, in combination with RSH8a's "The LocalDevice is initialised when first required", means that the check-and-discard should happen lazily when the LocalDevice is first required; we are instead performing it eagerly at storage init and thus at client init.
It's hard to think of many concrete negative consequences of this though; I originally wrote this but then realised that we do LocalDevice access also whenever the client becomes identified (to set its clientID) so really my speculated workaround (that might not be happening in practice anyway) is only useful for nonidentified clients.
It's plausible that some users have previously noticed that they were running into before-first-unlock id/secret regeneration issues and thus decided to work around this by not trying to access any push-related features until they have themselves verified that protectedDataAvailable is returning YES in order to avoid a device ID regeneration. By performing the migration eagerly we'd be breaking these workarounds.
Will leave it to you to consider and see if you think it's worth doing anything. Worst case behaviourally is a one-off device ID regeneration for hypothetical users who had been trying to avoid one. Also technically there's now a synchronous disk read on the caller thread (possibly main) on client init.
Originally posted by @lawrence-forooghian in #2207 (comment)
┆Issue is synchronized with this Jira Task by Unito
non-blocking: this technically doesn't actually conform to RSH8a1, which, in combination with RSH8a's "The LocalDevice is initialised when first required", means that the check-and-discard should happen lazily when the
LocalDeviceis first required; we are instead performing it eagerly at storage init and thus at client init.It's hard to think of many concrete negative consequences of this though; I originally wrote this but then realised that we do
LocalDeviceaccess also whenever the client becomes identified (to set itsclientID) so really my speculated workaround (that might not be happening in practice anyway) is only useful for nonidentified clients.Will leave it to you to consider and see if you think it's worth doing anything. Worst case behaviourally is a one-off device ID regeneration for hypothetical users who had been trying to avoid one. Also technically there's now a synchronous disk read on the caller thread (possibly main) on client init.
Originally posted by @lawrence-forooghian in #2207 (comment)
┆Issue is synchronized with this Jira Task by Unito