“When someone promises you and doesn’t deliver, you’d better insist.”

Have you ever been promised to receive a certain response from someone, for instance Mr.Axios and he didn’t really get to fulfill it because he might’ve been busy or something came up that prevented him to do so?

If that sounds familiar to you then don’t worry, i’ve got an excellent solution for your case, that would be Promise-Insist.

What is Promise-Insist?

Promise-Insist is a newly published typescript library written to handle certain promise-based scenarios in a neater fashion, scenarios critically depending on results to be returned by tasks/promises, ones we need to insist upon and re-attempt in case of failure whenever the conditions in charge are dynamic and prone to change.

In other scenarios we might want to cancel a certain re-attempting (insisting) task(promise) because another one or more event(s) of a higher priority just kicked in, and we don’t care about the older promise anymore, we are more greedy now, we want to insist on yet a more important promise! :).

What does Promise-Insist offer?

Retry (insist-on) a promise <retries> times every <delay> only if the <errorFilter> is whitelisted through global or task specific config

(insist-on) a promise <retries> times every <delay> only if the <errorFilter> is whitelisted through global or task specific config Cancel retrying a certain promise, or all currently being retried.

retrying a certain promise, or all currently being retried. OnRetry hook that executes per each retry per promise(<attemptNumber>,< timeConsumed>) => void

hook that executes per each retry per promise(<attemptNumber>,< timeConsumed>) => void Replace a task being retried by another one dynamically while maintaining the current configuration and retries count left (useful with things like rate-limits etc..)

A Close Encounter:

To better understand what the library offers and how to use it, we’ll imagine a real-world scenario in which we need to grab a critical response from a GET Request to a certain URL (http://localhost:1337).

Now if an error occurred during that request, it might be a wise idea to re-send it depending on the condition expressed by the error code. if the condition in charge of failure had the potential to change over time and yield a successful response, then we retry it, otherwise, it most likely is not going to happen, well then no point of retrying.

These sort of situations can be handled flexibly with promise-insist, let’s start off by creating an instance with a global configuration in which we can specify the Max Retries , Delay between each retry and the white-listing error filter.

Now as you can see in the above code, Promise-Insist comes with a couple of Error Filters & Delays presets, here we are using Axios’s Error Filters and the ExponentialDelay preset for exponential back-offs.

i chose to use the isRetryable which will allow retrying for all kind of errors that are worth retrying, ones in which the fault is not by a bad , malformed or an unauthorized request by you, but rather errors that can resolve with retries, like server errors or connection timeouts.

Now let’s go ahead and see how easy it is to make all that work with a little code:

that’s great so far, but what if we want to define a separate configuration than the global one, and also set a callback to execute on each retry? perhaps to increment some progress bar?

Now i need you to upgrade this scenario in your imagination and assume we have a WebSocket or any other async event source delivering certain data to POST to a certain URL as an update.

Also imagine that you might be getting such async events with data you need to update at any moment, so whatever was received last is what matters.

now what if the server you were trying to POST to was overloaded and you kept insisting on a response of a previously received data, but you now have to update it with the latest instead?

in that case we obviously would rather need to cancel retrying that specific request which overlaps with the newest since both are posting to the same URL target. Canceling is useful even if both tasks were totally different, but only one can exist at a time or maybe one should only cancel another specific task which overlaps at a certain part of the logic.

Luckily this library already supports canceling of promise retries, and it is very easy to do so.

One last but not least feature at the time of writing, is the ability to replace the promise context being insisted upon with another, while maintaining the remaining amount of retries and the same configuration.

Where can i check it out ?

Any technical docs ?

How can i help ?

You can definitely submit P.Rs and i’ll approve any enhancements.