-
Notifications
You must be signed in to change notification settings - Fork 64
Reporting non-existent orchestrations in start_new
#142
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
Conversation
…e-python into djusto/orchestration-client-exception
I forgot to ask - how hard would it be to add a unit test for this? I know we're able to pretty easily mock the HTTP stuff in Durable JS but I'm not as familiar with the Python test setup. |
Hmmm, I'd have to investigate the unit testing setup a little more. Mocking HTTP requests is easy, and I've done it before for other projects, I just need to double check that our testing framework makes that easy to incorporate in a white-box test. I'll get back to you |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome - looks good to me!
Heads up, added unit tests! Will merge now, thanks :) |
Excellent!!! Also, don't forget to delete your branch after each PR merge into |
Addresses: #141
We now throw an exception when start_new fails, whereas before we simply returned
None
. In doing so, we avoid throwing an internal exception (server response 500) when callingclient.create_check_status_response
.In practice, this meant that, before, users hitting an
HTTPTrigger
with a typo on the orchestration name would see an internal exception with little debug information. Now, we report the real cause of the error and suggest a fix: looking for typos.I would also love it if we could display this error, and others, as part of an HTTP response. Reading it on the terminal, while common practice, is not as nice, in my opinion.
Finally, this is also an error in Durable-JS.