Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Queue does not throw an error if it fails to connect to the provided reference. #62

Open
startswithaj opened this issue May 18, 2016 · 1 comment

Comments

@startswithaj
Copy link

startswithaj commented May 18, 2016

If you pass in a firebase ref that for instance doesn't have the correct read permissions when instantiating a Queue it does not throw it just logs the error? There's really no way of responding to this.

https://github.com/firebase/firebase-queue/blob/master/src/lib/queue_worker.js#L598

I can't see a way to tell programmatically if a queue worker subscription has been successfully established.

Should there be a function like Queue.shutdown such as Queue.status() that returns a promise that is resolved once all workers successful subscription to the ref has been made or rejected if it fails?

I realise the QueueWorker would have to have a status function that returns its connection state as well.

A less drastic change would be that the workers are not spawn until the ref connection is tested.

I'm happy to take a crack at a PR for this if you guys have suggestions?

A breaking change suggestion would be that Queue has a function called connect() or spawn(). That you call once you instantiate the object.

Cheers

@startswithaj startswithaj changed the title Queue does not throw and error if it fails to connect to the provided reference. Queue does not throw an error if it fails to connect to the provided reference. May 18, 2016
@startswithaj
Copy link
Author

startswithaj commented May 19, 2016

A couple of other things that I'm not sure how to handle correctly...

If an error is thrown inside the processing function a worker is running (object undefined etc), it's heavily guarded (which is what you want in a worker) and the error is written to the task. But there is no logging.

In production most of these types of unhandled errors shouldn't happen but it makes things slightly difficult for dev in the case where an error get thrown inside of that processing function you have to track down the errored/retired task and check the error details.

I feel like there should be an option to log out errorDetails inside the worker?

The solution is wrapping the worker code in a try/catch/promise logging the error and then throwing it again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant