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

[BUG] Deleting a not-found model or agent via the MLClient throws an exception #2751

Open
dbwiddis opened this issue Jul 25, 2024 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@dbwiddis
Copy link
Member

dbwiddis commented Jul 25, 2024

What is the bug?

When using the ML Client to delete a model or agent which does not exist, the ActionListener failure path is followed with an OpenSearchStatusException with status NOT_FOUND.

This does not match the pattern for Connectors and OpenSearch document deletion where the a DeleteResponse is sent indicating success, but includes a DocWriteResponse.Result.NOT_FOUND result.

How can one reproduce the bug?
Steps to reproduce the behavior:

  1. Use the MLClient to register a model or agent
  2. Use the REST API to delete that model or agent
  3. Use the MLClient to unregister/delete that model or agent
  4. The ActionListener fails with exception

What is the expected behavior?

ActionListener should send onResponse with a DeleteResponse with NOT_FOUND result.

Suggested FIx

Clearly document "delete" APIs that send DeleteResponse which do not follow the usual pattern.

@dbwiddis dbwiddis added bug Something isn't working untriaged labels Jul 25, 2024
@ylwu-amzn
Copy link
Collaborator

This will be a breaking change. If some user have code/scripts checking exception returned from delete API , their code will break.

Why not change the client side logic to check the error ?

@dbwiddis
Copy link
Member Author

I am changing the client. But this is an unusual pattern and should be clearly documented as such. MLClient users should not have to look in the code to see that deletion does not follow the same pattern as expected.

@ylwu-amzn
Copy link
Collaborator

Make sense, create a document issue to track this : opensearch-project/documentation-website#7838

@b4sjoo b4sjoo removed the untriaged label Jul 30, 2024
@b4sjoo b4sjoo self-assigned this Jul 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: On-deck
Development

No branches or pull requests

3 participants