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

[ML] Job in Index Feature: TransportJobTaskAction no longer detects unknown jobs #34747

Open
davidkyle opened this issue Oct 23, 2018 · 2 comments
Labels
:ml Machine learning team-discuss

Comments

@davidkyle
Copy link
Member

davidkyle commented Oct 23, 2018

TransportJobTaskAction checks the cluster state for the job configuration before looking for the job's persistent task. If the config cannot be found a missing jobs exception is thrown so all actions that extend TransportJobTaskAction automatically get job exists checking. With the change to move the config the job check has to be removed so in the case of an unknown job the error will be cannot perform action X as the job is not open, then of course opening the job would return the job not found error.

Discuss
Error messages are not part of the rest specification so is this considered a breaking change. Is the new behaviour acceptable or can anyone see a workaround?

The actions that extend TransportJobTaskAction and hence are affected are:

  • TransportFlushJobAction
  • TransportForecastJobAction
  • TransportPostDataAction
  • TransportUpdateProcessAction (internal)
  • TransportPersistJobAction (internal)
  • TransportKillProcessAction (internal)
@davidkyle davidkyle added :ml Machine learning team-discuss labels Oct 23, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/ml-core

@droberts195
Copy link
Contributor

I think it would be nice if the 3 actions that are designed for external use (TransportFlushJobAction, TransportForecastJobAction and TransportPostDataAction) would correctly report the job didn't exist.

I think there is a way to do this. TransportJobTaskAction could take an optional JobConfigProvider. The 3 internal actions would pass null for this; the 3 external actions would pass the one obtained by dependency injection. Then, on finding the job task didn't exist, instead of immediately returning a "job not open" error message, the TransportJobTaskAction could try to get the job config from the JobConfigProvider if one was provided. Any exception produced by that would be passed to the final listener, or if getting the config was successful then the "job not open" exception would be raised as now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:ml Machine learning team-discuss
Projects
None yet
Development

No branches or pull requests

3 participants