Conversation
| except ValueError as e: | ||
| yield format_message(message.MessageStreamError(reply.id, f"{e}", "Context length is too long")) |
There was a problem hiding this comment.
This would catch other ValueErrors right? I don't think we want to generalize every ValueError to a context length error.
There was a problem hiding this comment.
Also, how can we inform the UI that this is a context length error so it can show a special message with this?
There was a problem hiding this comment.
Any suggestion for the error name? Otherwise I'll use ValueError directly
There was a problem hiding this comment.
ValueError may work but flask_pydantic_api may catch it? I'd like to catch this kind of thing before it gets to this point tbh.
You may be able to raise an UpstreamError here instead of yielding a MessageStreamError?
There was a problem hiding this comment.
Also, how can we inform the UI that this is a context length error so it can show a special message with this?
The exception content is a string value. Are you suggesting parsing the string to determine whether it's a context length error?
There was a problem hiding this comment.
sorry, I meant that flask_pydantic_api has some handling around Pydantic types like this. If it's thrown directly it may do something special?
There was a problem hiding this comment.
Are you suggesting parsing the string to determine whether it's a context length error?
There's nothing else in it? I figured it may have more.
We may need to add request validation to have this show up nicely in the UI then. If that's more work than we want to take on right now we can put it off to another time.
| yield format_message(message.MessageStreamError(reply.id, err, "grpc inference failed")) | ||
|
|
||
| except multiprocessing.TimeoutError: | ||
| finish_reason = FinishReason.ModelOverloaded |
There was a problem hiding this comment.
It is changed to yielding error msg directly. I can change it back if you prefer the previous way
There was a problem hiding this comment.
Doesn't this affect how we save the message at the end?
There was a problem hiding this comment.
There was a problem hiding this comment.
Good call. Curious why only TimeoutError exception is saved as finish_reason. Should we save RpcError and ValueError in finish_reason when they happen?
There was a problem hiding this comment.
ValueError may be a good finish reason, maybe something like FinishReason.InvalidRequest? I think RpcError is caused by a bad connection to InferD, so we may not need to save that?
There was a problem hiding this comment.
I'll name it to BadConnection
There was a problem hiding this comment.
You may want to keep that as-is or change the UI as well. We have some code tied to these values. https://github.com/allenai/olmo-ui/blob/dev/src/api/Message.ts#L99-L119
There was a problem hiding this comment.
I'll raise a PR to add them
|
|
||
| except ValidationError as e: | ||
| return handle_validation_error(e) | ||
| except Exception as e: | ||
| return handle(e) | ||
|
|
There was a problem hiding this comment.
Why did this change? This was supposed to be a special case for ValidationErrors.
There was a problem hiding this comment.
What would happen if the error is not ValidationError type? I saw the handle() function has more handling over different error types.
There was a problem hiding this comment.
The flask error handler would handle it and return it as an exception. ValidationError handling is here to get around flask_pydantic_api's handling of ValidationErrors. I think you should revert this.


Closes: https://github.com/allenai/playground-issues-repo/issues/248
Improved error handling to show context length error msg