fix var name for backoff retry

[jjedd97]

Fix to address mismatch in variables names for reporters.js backoff value

Problem:

• If a message fails to send, the timer for HttpApi gets set to NaN

Original error:

`
(node:1) TimeoutNaNWarning: NaN is not a number.

Timeout duration was set to 1.

at new Timeout (node:internal/timers:199:17)

at setTimeout (node:timers:117:19)

at /server/node_modules/datadog-metrics/lib/reporters.js:15:30

at new Promise (<anonymous>)

at sleep (/server/node_modules/datadog-metrics/lib/reporters.js:15:11)

at HttpApi.send (/server/node_modules/datadog-metrics/lib/reporters.js:56:23)

at process.processTicksAndRejections (node:internal/process/task_queues:104:5)

at async DatadogReporter.sendHttp (/server/node_modules/datadog-metrics/lib/reporters.js:281:16)

at async Promise.all (index 0)

at async DatadogReporter.report (/server/node_modules/datadog-metrics/lib/reporters.js:225:13)
`

[Mr0grog]

This is simple enough that it’s pretty clear what’s going on, but in the future, please include a basic reproduction or and/or a clearer description of how you’d actually trigger the error you’re describing! The PR description was a little confusing at first.

I think the test needs a slight tweak (see inline comment), but otherwise this is great. Thanks for submitting a fix. 👍🏻

[Mr0grog]

Like the other tests here that cover retry delays, this should really be using .within() to test both a lower and upper bound. Otherwise this test would pass in the opposite situation if we accidentally wound up using a delay that was too big.

I also think it might be worth using a separate reporter instance for this one test so you can set a bigger backoff. The jitter you are accounting for here is a big percentage of the whole backoff time, which makes the test feel somewhat inaccurate. Also, the jitter accounted for needs to be bigger — I’ve already seen this fail locally for me once when running it.

I don’t think the backoff needs to be a whole second like it is in the next test, but it should probably at least be something like 100ms instead of 10.

[jjedd97]

On average it takes about 112ms for the test to run for me. At it's longest I observed 118ms. Happy to adjust the upper and lower bounds more if other environment produce a larger spread.

[Mr0grog]

Looks great, thanks!

[jjedd97]

Looks great, thanks!

Glad this got merged - Any chance you guys could publish a patch release for this?