Skip to content

Clear deviceIdentityToken when we fail to load id or deviceSecret#474

Open
lawrence-forooghian wants to merge 3 commits into
mainfrom
tighten-up-RSH8j
Open

Clear deviceIdentityToken when we fail to load id or deviceSecret#474
lawrence-forooghian wants to merge 3 commits into
mainfrom
tighten-up-RSH8j

Conversation

@lawrence-forooghian
Copy link
Copy Markdown
Collaborator

@lawrence-forooghian lawrence-forooghian commented May 13, 2026

A couple of minor bits and then a replacement of RSH8j (which is not implemented in most of our SDKs AFAIK — the important one in which it's not implemented is ably-cocoa since that's the one in which load failure is likely to happen, tracked in ably/ably-cocoa#1257). Intention is to make sure that you don't end up with a deviceIdentityToken that belongs to a previous id and to make it clearer how to implement "become NotActivated".

See commit messages for more details.

lawrence-forooghian and others added 2 commits May 13, 2026 16:01
The note in RSH8k2 mentioned RSH3a2b three times but only linked
the first reference. Link the other two for consistency.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The note previously said "our implementations" all generate eagerly,
but this isn't accurate. ably-java follows RSH3a2b (lazy generation
on CalledActivate); ably-cocoa and ably-js generate eagerly at device
fetch time.

Checked against:
- ably-cocoa 745e7b7
- ably-java da4c60f
- ably-js 17be43e

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Otherwise, the old token will survive and we'll end up trying to
validate it with an absent or non-matching device ID in RSH3a2a.

Given that most of our SDKs have not yet implemented RSH8j, it seemed
like a good moment to also tighten up the language before we start
trying to implement it. The spec provides no mechanism for the state
machine to perform a state transition outside of the context of
receiving an event. So instead of talking about a transition, we make it
clear that LocalDevice load failure should always be handled before the
state machine is hydrated.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant