Clear deviceIdentityToken when we fail to load id or deviceSecret#474
Clear deviceIdentityToken when we fail to load id or deviceSecret#474lawrence-forooghian wants to merge 4 commits into
deviceIdentityToken when we fail to load id or deviceSecret#474Conversation
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>
lawrence-forooghian
force-pushed
the
tighten-up-RSH8j
branch
from
6cf8bd6 to
8ce3ee1
Compare
|
There is a lot of back and forth between RSH8a, RSH8b, RSH3h, RSH8k2, RSH3a2b which makes it very hard to follow. Can we keep such a thing as "load details or generate if it doesn't exist or loading failed" in at least two places? Earlier this year I've tried to fit specs with current cocoa behavior and reducing amount of jumping between spec points, wdyt @lawrence-forooghian? - #181 Regarding loading failure - it's not like unrecoverable failure, right? Why generate new details if you can try to load a bit later when user unlocks device? |
|
Will answer your other points @maratal, but re
It's an option that I'd considered but when I discussed with Paddy he said he didn't think we should do this and instead should just make sure it's stored in a way that's always available. Bear in mind also that in ably-cocoa |
|
BTW I've added 5ccc1d1 to remove a statement I didn't realise existed which seems quite redundant |
lawrence-forooghian
force-pushed
the
tighten-up-RSH8j
branch
from
8ce3ee1 to
02f6852
Compare
I didn't even know that this statement existed. Paul added it to RSH3a2b in a6e9e18 but then added RSH8j in 17d4a2a a couple of weeks later, both in the same PR [1]; the former seems to be a vaguer version of the latter. [1] ably/docs#1062
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>
lawrence-forooghian
force-pushed
the
tighten-up-RSH8j
branch
from
02f6852 to
5ccc1d1
Compare
What are some examples of jumping-around that you think we could remove?
It seems like that PR is largely orthogonal to the current one; that's about when the device ID and secret should be regenerated. But if you think that merging that one would allow us to simplify this one, I'm happy to hear how. My worry about merging that one is, as described in 9871e20, we'd be replacing a spec point that describes how it's currently implemented in ably-java with one that describes how it's currently implemented in ably-cocoa and ably-js; I'd prefer that if we're going to do that then we also align the implementations. |
yes, sorry |
2 participants
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
deviceIdentityTokenthat belongs to a previousidand to make it clearer how to implement "becomeNotActivated".See commit messages for more details.