-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
"Task exception was never retrieved" in ChainlitDataLayer.update_step() #1232
Comments
I'll produce a PR with a candidate fix. I'm wondering whether this is best handled in the chainlit library or in the literalai client. |
@oshoma Thanks! Looking forward to that! It seems to me that the cleanest developer experience when working with a library is when only well-defined exceptions are produced and so, underlying errors like I/O should be wrapped. In addition, retry logic can then be implemented on a library level. So, to answer your question; indeed, the LiteralAI client lib seems the place. When wrapping, take care to distinguish:
Ref: https://roman.pt/posts/temporary-vs-permanent-errors/ This is not only relevant for retry logic, it's also relevant for UX (e.g. no need for the user to keep retrying if they'll actually be triggering the same bug, better to just show them there's a bug and whatever they tried won't work until it's fixed). |
@dokterbob Yes I agree it would be better to make the changes to the LiteralAI library rather than Chainlit. Is LiteralAI development happening in a git repo somewhere I can contribute? I see I can download files from https://pypi.org/project/literalai/#files but there is no link to a repo. |
@dokterbob looking further at I don't want to disturb that strategy as doing so could break API clients. So I'm going to submit a PR for Chainlit instead of a patch for LiteralAI. |
Fixes Chainlit#1232 Modify Chainlit so that HTTP errors which occur while sending steps to LiteralAI are caught and logged. Prior to this change, HTTP errors such as timeouts result in a series of cascading exceptions and tracebacks that begin with "Task exception was never retrieved" and continue for several traceback iterations. The result is a very verbose log which is hard to understand. With this change we will see one-line error messages in the log rather than a series of tracebacks. In the future we might want to improve this further by retrying (sending the steps again) when the HTTP error is temporary.
Fixes Chainlit#1232 Modify Chainlit so that HTTP errors which occur while sending steps to LiteralAI are caught and logged. Prior to this change, HTTP errors such as timeouts result in a series of cascading exceptions and tracebacks that begin with "Task exception was never retrieved" and continue for several traceback iterations. The result is a very verbose log which is hard to understand. With this change we will see one-line error messages in the log rather than a series of tracebacks. In the future we might want to improve this further by retrying (sending the steps again) when the HTTP error is temporary.
I think it might be wise to take this up with LiteralAI. @willydouhard What's your stance? |
I've just discussed it with @willydouhard, LiteralAI's CTO;
|
Closing this as I feel your PR addresses the issue sufficiently (for now). |
Fixes #1232 Modify Chainlit so that HTTP errors which occur while sending steps to LiteralAI are caught and logged. Prior to this change, HTTP errors such as timeouts result in a series of cascading exceptions and tracebacks that begin with "Task exception was never retrieved" and continue for several traceback iterations. The result is a very verbose log which is hard to understand. With this change we will see one-line error messages in the log rather than a series of tracebacks. In the future we might want to improve this further by retrying (sending the steps again) when the HTTP error is temporary.
Describe the bug
When running my Chainlit app I sometimes see a series of exception messages and tracebacks in the log that begin with "Task exception was never retrieved". As best I can tell, these come from unhandled HTTP exceptions such as
httpx.ConnectTimeout
,httpx.RemoteProtocolError: Server disconnected without sending a response.
and the like. I believe the source is whenChainlit.data.__init__.py
callscreate_step()
and encounters an HTTP error.To Reproduce
Expected behavior
The app should catch HTTP exceptions and either retry or fail gracefully.
The app should produce debug log statements to indicate the exceptions are happening.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Additional context
Sample stack trace:
The text was updated successfully, but these errors were encountered: