Skip to content

Show context length error msg#262

Merged
yensung merged 8 commits intomainfrom
248ContextLengthError
Apr 7, 2025
Merged

Show context length error msg#262
yensung merged 8 commits intomainfrom
248ContextLengthError

Conversation

@yensung
Copy link
Copy Markdown
Contributor

@yensung yensung commented Apr 2, 2025

Closes: https://github.com/allenai/playground-issues-repo/issues/248

Improved error handling to show context length error msg

Screenshot 2025-04-02 at 12 55 07

@yensung yensung requested a review from mtblanton April 2, 2025 19:55
Comment on lines +408 to +409
except ValueError as e:
yield format_message(message.MessageStreamError(reply.id, f"{e}", "Context length is too long"))
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would catch other ValueErrors right? I don't think we want to generalize every ValueError to a context length error.

Copy link
Copy Markdown
Contributor

@mtblanton mtblanton Apr 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, how can we inform the UI that this is a context length error so it can show a special message with this?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any suggestion for the error name? Otherwise I'll use ValueError directly

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ValueError may work but flask_pydantic_api may catch it?

How do you catch it in flask_pydantic_api? I only see they are all ValueError here
Screenshot 2025-04-02 at 12 01 48

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't look like a pydantic error type

Screenshot 2025-04-03 at 09 50 20

yield format_message(message.MessageStreamError(reply.id, err, "grpc inference failed"))

except multiprocessing.TimeoutError:
finish_reason = FinishReason.ModelOverloaded
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this removed?

Copy link
Copy Markdown
Contributor Author

@yensung yensung Apr 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is changed to yielding error msg directly. I can change it back if you prefer the previous way

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this affect how we save the message at the end?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call. Curious why only TimeoutError exception is saved as finish_reason. Should we save RpcError and ValueError in finish_reason when they happen?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll name it to BadConnection

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll raise a PR to add them

Comment on lines 49 to 51

except ValidationError as e:
return handle_validation_error(e)
except Exception as e:
return handle(e)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did this change? This was supposed to be a special case for ValidationErrors.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would happen if the error is not ValidationError type? I saw the handle() function has more handling over different error types.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@yensung yensung requested a review from mtblanton April 3, 2025 18:39
yensung added 2 commits April 4, 2025 14:13
* main:
  increase timeout to receive first token (#263)
  handle the server-overloaded case (#261)
Copy link
Copy Markdown
Contributor

@mtblanton mtblanton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work!

@yensung yensung merged commit cf87e5f into main Apr 7, 2025
3 checks passed
@yensung yensung deleted the 248ContextLengthError branch April 7, 2025 16:26
mtblanton pushed a commit that referenced this pull request Jun 13, 2025
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

Successfully merging this pull request may close these issues.

2 participants