catch unhandled rejection / errors

[cjroebuck]

Hey thanks for this lib, very useful!

Occasionally I receive a 404 error from the kubernetes API, this is usually when a pod is starting up. This causes the promise in your lib to reject:

HTTPError: Response code 404 (Not Found)
    at EventEmitter.emitter.on (/usr/src/app/node_modules/preoom/node_modules/got/source/as-promise.js:74:19)
    at process._tickCallback (internal/process/next_tick.js:68:7)

podmetrics.metrics.k8s.io "default/my-test-pod" not found

Right now it seems I can't catch these errors in your lib as they're running in a different async context to the calling code so they only get caught by my unhandledRejection handler. Is there a way to handle this?

[gajus]

What is the expected behaviour in this case?

[gajus]

I would suggest to simply delay initialisation of preoom.

[cjroebuck]

Hey there, it would be great if you could wrap a try/catch around your observe function and then pass any caught error back as the first arg of the callback.

That way the caller can decide how they want to handle the errors. Otherwise it will only be handled by an unhandled rejection handler which is not great.

I ran this in my cluster today and got a ton of 404 errors due to pods being scaled up /down and evicted etc so it seems to be fairly common to get these errors due to metrics not being ready in time

[gajus]

Hey there, it would be great if you could wrap a try/catch around your observe function and then pass any caught error back as the first arg of the callback.

The callback is only called once, though. It would need to be an event handler.

[gajus]

I ran this in my cluster today and got a ton of 404 errors due to pods being scaled up /down and evicted etc so it seems to be fairly common to get these errors due to metrics not being ready in time

So how would you handle this case that you are describing?

[cjroebuck]

The callback to observe function is called on a timer, right? It's here where the error could be caught and given back to the caller.

…

On Sat, 7 Dec 2019 at 23:52, Gajus Kuizinas ***@***.***> wrote: I ran this in my cluster today and got a ton of 404 errors due to pods being scaled up /down and evicted etc so it seems to be fairly common to get these errors due to metrics not being ready in time So how would you handle this case that you are describing? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=AAAC7MDNI57EAVXEE4C2ZWLQXQZMLA5CNFSM4JWD6FQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGSCZA#issuecomment-562897252>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAC7MDPNFSWYOZ7ZR4KKULQXQZMLANCNFSM4JWD6FQA> .

[cjroebuck]

Basically, wrap a try/catch round here[1]. It will catch any errors from the await getPodResourceUsage() call and pass them back in the callback.

1. preoom/src/factories/createResourceObserver.js

   Lines 69 to 78 in f7ce704

   	const context = await ready;
   	const podResourceSpecification = context.podResourceSpecification;
   	const podResourceUsage = await getPodResourceUsage();
   	log.debug({
   	podResourceSpecification,
   	podResourceUsage
   	}, 'observed resource usage');

[gajus]

🎉 This issue has been resolved in version 3.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[cjroebuck]

Thanks, using this version now, working well!

[danielyaa5]

I don't think this is working