This lib does not work no node_threads
See original GitHub issueHey there, nice work on this lib!
I am having trouble to use on node.js for some reason it does not retry. I am already using axios interceptors for request to put the Bearer JWT Token on place. Any hints?
let api = axios.create({
baseURL: baseURL,
headers: {
'Content-Type': 'application/json',
},
});
const myRaxConfig = {
// Retry 3 times on requests that return a response (500, etc) before giving up. Defaults to 3.
retry: 3,
// Retry twice on errors that don't return a response (ENOTFOUND, ETIMEDOUT, etc).
noResponseRetries: 3,
// Milliseconds to delay at first. Defaults to 100. Only considered when backoffType is 'static'
retryDelay: 1000,
// HTTP methods to automatically retry. Defaults to:
// ['GET', 'HEAD', 'OPTIONS', 'DELETE', 'PUT']
httpMethodsToRetry: ['GET', 'HEAD', 'OPTIONS', 'DELETE', 'PUT'],
// The response status codes to retry. Supports a double
// array with a list of ranges. Defaults to:
// [[100, 199], [429, 429], [500, 599]]
statusCodesToRetry: [
[100, 199],
//[429, 429], 429 eh o retorno de too many requests
[500, 599],
],
// If you are using a non static instance of Axios you need
// to pass that instance here (const ax = axios.create())
instance: api,
// You can set the backoff type.
// options are 'exponential' (default), 'static' or 'linear'
backoffType: 'static',
// You can detect when a retry is happening, and figure out how many
// retry attempts have been made
onRetryAttempt: (err) => {
const cfg = rax.getConfig(err);
childLogger.error(`myRaxConfig Retry attempt #${cfg.currentRetryAttempt}`);
},
};
api.defaults.raxConfig = {
instance: api,
};
const interceptorId = rax.attach(api);
Simple config, nothing fancy.
I am using basico post methods
api.post('/delete', {
myvar: myvar,
})
.then(function (response) {
}).catch(function (error) {
console.log(error);
});
So to test I am shuting down the server and getting ECONNREFUSED but there is no retry on them, it´s going directly to .catch. Any hints? Thanks!
Issue Analytics
- State:
- Created a year ago
- Comments:12 (3 by maintainers)
Top Results From Across the Web
Library does not work in node worker threads - Module did not ...
I've seen this with a few native modules that when they try to be used within the new NodeJS Workers feature they don't...
Read more >Is saying "there are no threads in nodejs" correct?
So it is true that Node. js has no threads, but it is because it's the way JavaScript works. Node.
Read more >Node.js, not works only in single thread by default
By default, node.js only uses ONE thread to run your Javascript. Thus your Javascript runs as single threaded. No two pieces of your ......
Read more >A complete guide to threads in Node.js - LogRocket Blog
Since worker pool has its own threads, the event loop can continue executing normally while the file is being read.
Read more >On problems with threads in node.js | Kariera Future Processing
The libuv library maintains a pool of threads that is used by node.js to perform long-running operations in the background, without blocking its...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Sure! So an HTTP POST could result in changes being made to the state of the data on the server. When you get something like a 500 response code from a web server, that really makes it unclear to any client if the actual changes desired by the request have been reflected on the backend. As a result, retrying a POST request is considered dangerous - after the second POST, you can’t confirm the state of the data on the backend (in a general sense). This is kind of unique to a POST:
… and so on. If you specifically know exactly what your backend will do, and decide that a POST is safe to retry … go for it!
Solved with some tweaks