3 ms·

> The user could have gotten logged out somehow, or maybe there's a rate limit or something All your examples are retryable errors in which the prescription is

by Spivak 2y ago

> The user could have gotten logged out somehow, or maybe there's a rate limit or something All your examples are retryable errors in which the prescription is the same: "keep the message queued until it's successful." And when all your failure modes are like this optimistic-no-feedback works. If you have non-retryable errors in your failure modes "Bad Request", "Gone" this pattern can't be used.

deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
ben-schaaf 2y ago
Not being logged in is not a retryable error.
- Spivak 2y ago
  Sure it is, why wouldn't it be? Keep it stored and queued until they log in again. It's the same as being offline.
  - xbjfk 2y ago
    What if someone else logs in?
    - Spivak 2y ago
      Your local storage, and hence the queue, isn't segmented by user?
yuliyp 2y ago
Sure they're retryable. But those retries might never succeed (user wipes their phone or uninstalls the app or logs out or clears local app data or a buffer fills up to come up with a few scenarios. Either the request didn't matter to the user at all, in which case sure whatever, or at some point they're going to discover that the thing they thought happened didn't actually happen.