We should carefully consider this one. We have a major customer that has been complaining about 5xx spam in their logs. Perhaps we make sure we're using exp backoff for all FE retries.

I think there's a subset of cases we must have retries for initial release, e.g. build status, which is what I assume the /buildinfo refers to. I think exponential can be pretty simple, but I'm also not worried about the 5xx spam for our initial release. You have to get to a certain level of scale with a higher sensitivity to log alerts for that to be a problem. Certainly we should do sensible things, but we shouldn't require it for EE MVP.

I prefer to make retries explicit when possible, and am actively keeping this in mind. These thoughts motivated my comments here:

#1362 (comment)

I've added an explicit retry in other work in this codebase, for example see here:

#1690

and in particular the storybook from that PR here:

https://624de63c6aacee003aa84340-uhekdmgbxi.chromatic.com/?path=/story/components-errorsummary--with-retry

In #1701 you can see that we need to initially fetch a workspace. If we fail that initial fetch (required to present the form), we are in the error state which will only respond to events asking to refetch the workspace. The user creates those events by clicking a retry button.

https://github.com/coder/coder/pull/1701/files#diff-7ff27b63cc1e789c57e83e305d37e17fb77a250aeab66c477ea2723782716cceR57-R72

https://github.com/coder/coder/pull/1701/files#diff-7ff27b63cc1e789c57e83e305d37e17fb77a250aeab66c477ea2723782716cceR93-R98

https://github.com/coder/coder/pull/1701/files#diff-6479a1168ce67746239902a493ef38452c899d19da0741eb84812f89e47e3aa0R64-R65

I think this (or similar) is the pattern we should lean on.

Could these implementations be unified by waiting until some event happens? Then we wait for a user triggered event when we want the user to click a retry button and some timer event or something when we want to do background retries.

Could these implementations be unified by waiting until some event happens? Then we wait for a user triggered event when we want the user to click a retry button and some timer event or something when we want to do background retries.

Absolutely!

This is already the case based off of the xstate solution described above: some piece of code sends the model an event, and the model refetches in response to that event.

If we want the event to be raised from the background, rather than user action, we could have some process that does something like:

while (some condition not met) {
  await (some back off)
  send(RETRY_API_CALL)
}

The user action case just looks like

<button onClick={() => send(RETRY_API_CALL)} />

If we want the model to be responsible for computing backoff, that can also be plugged into the model. I'm not sure how the background looks in that case, maybe something like

const poll = setInterval(() => send(RETRY_API_CALL), 2000)
if (someCondition) {
  clearInterval(poll)
}

Either/or can be designed.