You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
is this issue currently blocking your project? (yes/no): no
is this issue affecting a production system? (yes/no): yes
Context
node version: 12 (we have several applications that use bell, but they're mostly on some version of node 12)
module version: 12.2.0
environment (e.g. node, browser, native): node
used with (e.g. hapi application, another framework, standalone, ...): hapi application
any other relevant information:
What problem are you trying to solve?
Many providers have some sort of rate limiting that can cause requests to fail, but these requests can succeed just by retrying them later, with the time to retry often being specified in the response headers. This issue is for the Okta provider specifically because it's what we're using, but handling rate limiting could help with other providers too. It would be ideal to handle retrying these requests within bell so that consumers don't have to redirect back to the login or anything weird. The consumer could also specify a maximum number of tries to attempt before failing, with a default (maybe 3). See this documentation from Okta on rate limiting for more information on their rate limiting and the headers it uses.
Do you have a new or modified API suggestion to solve the problem?
Possibly a new option when configuring a provider to specify the max retries
The text was updated successfully, but these errors were encountered:
Support plan
Context
What problem are you trying to solve?
Many providers have some sort of rate limiting that can cause requests to fail, but these requests can succeed just by retrying them later, with the time to retry often being specified in the response headers. This issue is for the Okta provider specifically because it's what we're using, but handling rate limiting could help with other providers too. It would be ideal to handle retrying these requests within bell so that consumers don't have to redirect back to the login or anything weird. The consumer could also specify a maximum number of tries to attempt before failing, with a default (maybe 3). See this documentation from Okta on rate limiting for more information on their rate limiting and the headers it uses.
Do you have a new or modified API suggestion to solve the problem?
Possibly a new option when configuring a provider to specify the max retries
The text was updated successfully, but these errors were encountered: