Feat / access check retry mechanism

[royschut]

Access check retry mechanism

This PR adds a retry mechanism to the access check (reloadActiveSubscription()), to make sure that the UI notices granted access, even if the backend takes longer to process a purchase. This also makes it possible to reduce the initial delay. Note: I've left the initial delay after a subscription switch on 3000ms, because a switch presumably always takes long (it was initially set to 7500).

Note

This PR depends on the flaky subscription e2e test fix by @ChristiaanScheermeijer: #494

[royschut]

Hi @AntonLantukh and @dbudzins, could you have a look at this PR?

@ChristiaanScheermeijer Maybe you can reply on #494, which this one depends on?

[dbudzins]

I guess there is at least 1 edge case that this won't behave as intended for; if the viewer already has a subscription and is buying another one to access additional content. Would it be possible to pass an ID or something to the retry / wait recursion so we can keep trying until we see the expected new subscription?

[royschut]

Hm, good suggestion. With the suggested background polling in mind, perhaps we can create a checkSubscription(id) method? We could use it from useCheckAccess(), to make sure that the correct subscription is awaited.

[dbudzins]

Should we do some sort of backoff on this? Like retryDelay *= 2, so we cast a wider net?

[royschut]

Interesting suggestion. I'd have to keep some state. Perhaps a good option for an updated version as suggested?

[dbudzins]

reloadSubscriptions is used in a lot more places than I would have guessed. Does it make more sense to have a background worker that can just always listen / recheck subscription status? We could have it setup to poll periodically every 5 minutes or something and then when we trigger a change where we expect updates, we can kick it to refresh more frequently until we see an expected new state or a delay backoff reaches the slow polling frequency again? This would also have the benefit that we'd automatically update changes they may occur from external triggers.

[royschut]

reloadSubscriptions is used in a lot more places than I would have guessed. Does it make more sense to have a background worker that can just always listen / recheck subscription status? We could have it setup to poll periodically every 5 minutes or something and then when we trigger a change where we expect updates, we can kick it to refresh more frequently until we see an expected new state or a delay backoff reaches the slow polling frequency again? This would also have the benefit that we'd automatically update changes they may occur from external triggers.

Thanks for your feedback @dbudzins!
I like your suggestion, because it would simplify reloadSubscriptions, and it creates an additional fallback to infinitely reload every so many minutes. I was thinking something like the snippet below, where we keep it simple and only update the AccountController. The reloadSubscriptions method can then be simplified, removing all retry/delay logic. What do you think?

  defaultPollInterval = 5 * 60 * 1000;
  currentPollInterval = this.defaultPollInterval;

  pollSubscriptions = async () => {
    await this.reloadSubscriptions();
    setTimeout(() => {
      if (this.currentPollInterval < this.defaultPollInterval) {
        this.currentPollInterval = Math.min(this.currentPollInterval * 1.5, this.defaultPollInterval);
      }
      this.pollSubscriptions();
    }, this.currentPollInterval);
  };
  acceleratePolling = async (initialDelay: number = 0, acceleratedInterval: number = 1000) => {
    setTimeout(() => {
      this.reloadSubscriptions();

      this.currentPollInterval = acceleratedInterval;
    }, initialDelay);
  };

However, I don't have the time at this moment to refactor and thoroughly test this. It could mess up the UI due to the loading state that keeps toggling unexpectedly. Perhaps we could proceed with this PR, and I could work on a separate PR during the next sprint?