Is a specific instance of a more general fault where context could be lost during async operations. This case was noticed because the recently added code to store and flush data to shared storage takes long enough that Flutter has an increased chance to destroy the old context and this actually happened on some devices. I've investigated other instances of this problem and either developed a more defensive algorithm or commented when it is uncertain whether the problem is applicable or not.

Service changes:

• [ ] Create a new DB field to store a hint up to 128 characters long
• [ ] Field contents will be encrypted using same PII encryption key as used for customer email address
• [ ] Create a new API endpoint to receive a user's request to see their hint
• [ ] API will be public but rate-limited
• [ ] API endpoint will record user's email address and hint (both encrypted) in a pendingHintEmail DB, along with timestamps and request metadata
• [ ] Changes to that DB will trigger a function to send an email to the user
• [ ] Email will contain the hint if available, general tips on trying variations of a theme and a link to start the account reset process if all else fails

App UI changes:

• [ ] Add a "send me my hint" button or link at the same places as the account reset process can be requested.
• [ ] Add an optional field to the account registration page in KV1 (and 2 if Google/Apple ever allow us to register users within the app)
• [ ] Add an optional field to the account management page in KV1 (and 2 once that is implemented for changing the password)

Given that this is a lot of work and users can workaround the absence of this feature by recording their hint somewhere else, it's not a high priority task but it would add an additional level of reassurance to the user during the initial account signup.

If there are hundreds of entries to filter, it can sometimes be unclear that anything is happening after text is entered, particularly on slow devices.

We currently select the root group but it would be better for the user if we selected the next possible ancestor in the group hierarchy.

Currently we need to handle this in group_tree.dart (reFilter) and filter_cubit.dart

In remote_service.dart: _doRequest , we automatically retry a few times if the connection fails. That sorts us for 99.9% of failures but some edge cases could still be recoverable if we were to introduce some short delays to the retry attempts, depending upon what we can estimate the cause of the failure to be.

Maybe a parcelable unique ID?

Current implementation relies on consistent JSON stringification of Android-supplied metadata so not sure if one of these issues can occasionally occur:

• App fails to return to normal mode after restore following aborted autofill save attempt
• App fails to save supplied credentials if they are the same and from the same source as the most recent request to save

We only need this 2nd read for subscribed users that might be working on their Vault while a new one is being downloaded and merged in the background (or in the rare case when a free user first attaches to an existing remote account). So we could defer the read/unlock effort until really needed if we know we have no current User.

Low priority since we will first investigate if we can make changes to the sync operations so that they can be really done as a background operation while the app is not even open and thus remove this 2nd read operation for all users at the same time.