Skip to content

Conversation

@matthewrfennell
Copy link
Owner

No description provided.

In general, when we use a promise, we want to perform different UI
actions depending on whether the promise is fulfilled or rejected. For
instance, if a promise is rejected with an error from the server, we
may want to show an alert to the user detailing the error, so they know
whatever action they took wasn't successful.

In a regular scenario (already working), the UI would be notified of
the error like so:

1) user triggers some action which creates a handler and MLPromise
2) user puts the app into the background
3) server responds with an error - app extension is awoken
4) handler gets run in app extension, resolving the promise with error
5) user opens the app (restoring the state from before)
6) the promise is consumed, calling the AnyPromise that notifies the UI

However, before this commit, it was possible for an error from the
server to be silently dropped without alerting the user, if the user
closed the app after the promise was resolved.

Consider the following scenario (fixed by this commit):

1) user triggers some action which creates a handler and MLPromise
2) user puts the app into the background
3) server responds with an error - app extension is awoken
4) handler gets run in app extension, resolving the promise with error
5) user closes the app
6) user opens the app (fresh start: resolvers map is gone)

Now, the promise created in 1) is stale (since the AnyPromise returned
to the UI in 1) is not around anymore), so no popup is shown to the
user.

But, the action the user took was not successful, and without an error
they may not be aware that the change did not go through, causing
confusion when they realise this.

Therefore: if we attempt to consume a stale, rejected promise, post an
error so that a banner can be shown to the user with the error details.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants