An offline device may hold a private copy of follows and playback state. If an account is deleted elsewhere, that device should not recreate the removed cloud state when it reconnects.
This is a lifecycle problem, not simply a local-storage problem. The server needs a clear account status, and the client needs to respect it before uploading pending changes.
Define the reconnect rule
After restoring a session, check that the authenticated account and listener mapping are still valid. A rejected or deleted account should lead to a deliberate signed-out or recovery state, not an automatic “create listener” operation using old local data.
Keep pending writes tied to the account that created them. If another person signs in on the device, those writes must not move into the new account. An upload queue should carry ownership information as well as the requested change.
If the user later creates a genuinely new account, decide whether local data can be offered as an explicit import. Ask through a clear product flow instead of silently undoing the earlier deletion choice.
Exercise the difficult sequence
On device A, save a follow and go offline. On device B, delete the account through the supported flow. Reconnect A and try to resume. The result should follow your account lifecycle rules and should not restore the deleted listener automatically.
Repeat with an expired token and with a failed deletion request. The client must distinguish an operation that completed from one that merely started.
Keep retention and deletion claims aligned with your actual service behavior. The API can provide a deletion operation, while your app remains responsible for its offline queue and local copies.