Add optional maintenance mode retry handler for short downtimes

[ChristophWurst]

For nextcloud/mail#5714.

See the readme changes for a description.

This is a bit of an experiment, so I'm making this optional for now. If we find out that this is the way to go by default we can make it default enabled in a major version bump.

Babel-jest added to test the new module.

This only works with nextcloud/server#33173, so Nextcloud 25.

[tcitworld]

Maintenance windows are often more than 12 seconds, you would be very lucky to hit the end of a maintenance during a retry. 🤔

[ChristophWurst]

Maintenance windows are often more than 12 seconds, you would be very lucky to hit the end of a maintenance during a retry. thinking

Yeah, guess it could be a bit longer. The goal is to bridge the time for short maintenance outages, e.g. when an admin updates an app. If the instance goes down for longer maintenance it will require different handling.

So what could be a good grace period? Wait 1m? If it's too long the user might assume that the app crashed.

[tcitworld]

If it's too long the user might assume that the app crashed.

There must be some way (events ?) to help the UI tell the user something like « Server currently unavailable, retrying… (1/X) »

[ChristophWurst]

Fair enough but that has no place in the HTTP lib. You would need to debounce and combine the UI notifications because there could be many concurrent requests that run into a retry mode.

[ChristophWurst]

Added exponential retry delays and updated the documentation to make the goal of this change more clear.

[vinicius73]

The type definitions of request must be created to include this new value.
Otherwise, all typescript code will get errors if we use this.

[ChristophWurst]

Will be good to have some unit tests for it.

Done :)

[ChristophWurst]

The type definitions of request must be created to include this new value.
Otherwise, all typescript code will get errors if we use this.

How can I achieve this?

[vinicius73]

How can I achieve this?

It should be possible, but not anymore.

I've tried it locally, but the actual axios type definition do not work to customize the config anymore.

axios/axios#3672
axios/axios#1964

I've found a package who create a whole new one instance of axios to resolve it.

https://github.com/Weffe/axios-api-versioning/blob/d3bbde777872ac35d26940337ace1f63fcfb7d02/src/types/axios/axios.types.ts

[ChristophWurst]

Regarding typing we are only going to have issues for projects that use typescript, right? The apps I want to make use of this use javascript, so it won't be an issue.

It is not ideal if ts will complain about the extraneous property on the config objects but as long as this feature is opt-in I would not see it as big issue.

[danxuliu]

config, response and request may not be defined in some cases, so with this pull request trying to destructure request: { responseURL } fails in those cases (error.request is undefined). This can be seen when a request is canceled in Talk, although I do not know if the problem is specific to using the deprecated CancelToken or if it happens too when a request is aborted using the AbortController (or in other cases).

[ChristophWurst]

Could you file a ticket please @danxuliu? I assume there is no request if the abortion happens before any XHR connection is established

[danxuliu]

Could you file a ticket please @danxuliu? I assume there is no request if the abortion happens before any XHR connection is established

Done: #548