Non-persistent push state machine states conflict with RSH3

[tcard]

RSH3 states, kind of abstractly, that the state machine should run "as if" it were a concurrent process that outlives both the Rest/Realtime instances and the native apps that run them.

Having states that aren't persisted is in conflict with this; if the app stops while we're at one of such states, the state machine will find itself in an outdated state.

The original thinking for having non-persistent states is that they're always states that wait for a request completion (device registration/deregistration or update), and in-flight requests can't be persisted. So if the app is killed before request completion, we just go back to the state before the request started (which is kind of an "irregular" state transition) and "hope" that we get the event that retries such request again.

But this has two problems:

• It breaks RSH3's abstract model.
• We may not get ever that "retry" event; code that relies on RSH3 for correctness may prevent that kind of event. (This happens on Cocoa already.)

I think the cleanest solution here is to persist a representation of the awaited request as part of the "waiting for request completion" persistent states, and, on re-awaking the state machine on such states, make the associated requests again. (These request retries should always work because those requests are supposed to be idempotent.)

┆Issue is synchronized with this Jira Bug by Unito

[paddybyers]

I think the cleanest solution here is to persist a representation of the awaited request as part of the "waiting for request completion" persistent states, and, on re-awaking the state machine on such states, make the associated requests again.

sgtm