After upgrading to 8.0.0 rc2, error is thrown when editing watchers created in 6.8.23 #83235
Comments
elasticmachine
added
the
Team:Data Management
|
Pinging @elastic/es-data-management (Team:Data Management) |
|
We don't write anything to the deprecation info API, but we do write it to the deprecation logs. Did you check the deprecation logger critical messages? When I try to reproduce this, I see this in the logs: Or are you saying that it doesn't appear in there either? I didn't know which job you were talking about starting, so I just created a custom watcher with an empty types array while I was in 6.8. |
|
@masseyke thank for taking a look. yes, I am seeing |
|
The deprecation logs are now on a separate page in the upgrade assistant, that is linked from a sentence that says, "If you have application code that calls Elasticsearch APIs, review the Elasticsearch deprecation logs to make sure you are not using deprecated APIs." - see elastic/kibana#118659. This was done because we don't know that a critical deprecation log is something that comes from within the cluster and is bound to still exist after upgrade rather than some external client that might not send its obsolete request again. So I think there's a UX issue here in that it's easy for a user to miss that one of the deprecation logs among potentially many coming from external clients comes from within the system. With "if you have application code that calls Elasticsearch APIs" we're not making it obvious to the user that the application code in question might live inside the Elasticsearch JVM 😆 . Since the ML UI in 6.x created watches with a |
|
Pinging @elastic/ml-core (Team:ML) |
masseyke
removed
:Data Management/Watcher
Team:Data Management
|
We discussed this and decided it would be easier and safer for the Watcher code that parses the search in 8.0 and above to ignore the |
In 6.x internal system components created Watches with an empty types array in their definition. Types do not exist in 8.x, so these system-created Watches would need to be modified in 7.x to remove the types field. Because doing such modifications as a secret background task could be risky, instead the 8.x Watch parser will tolerate and ignore an empty types array. It is clear that an empty types array can be considered identical to typeless. Non-empty types arrays will still be considered fatal errors in 8.x, as silently ignoring them could change the meaning of the search. Fixes elastic#83235
In 6.x internal system components created Watches with an empty types array in their definition. Types do not exist in 8.x, so these system-created Watches would need to be modified in 7.x to remove the types field. Because doing such modifications as a secret background task could be risky, instead the 8.x Watch parser will tolerate and ignore an empty types array. It is clear that an empty types array can be considered identical to typeless. Non-empty types arrays will still be considered fatal errors in 8.x, as silently ignoring them could change the meaning of the search. Fixes #83235
In 6.x internal system components created Watches with an empty types array in their definition. Types do not exist in 8.x, so these system-created Watches would need to be modified in 7.x to remove the types field. Because doing such modifications as a secret background task could be risky, instead the 8.x Watch parser will tolerate and ignore an empty types array. It is clear that an empty types array can be considered identical to typeless. Non-empty types arrays will still be considered fatal errors in 8.x, as silently ignoring them could change the meaning of the search. Fixes elastic#83235
In 6.x internal system components created Watches with an empty types array in their definition. Types do not exist in 8.x, so these system-created Watches would need to be modified in 7.x to remove the types field. Because doing such modifications as a secret background task could be risky, instead the 8.x Watch parser will tolerate and ignore an empty types array. It is clear that an empty types array can be considered identical to typeless. Non-empty types arrays will still be considered fatal errors in 8.x, as silently ignoring them could change the meaning of the search. Fixes elastic#83235
In 6.x internal system components created Watches with an empty types array in their definition. Types do not exist in 8.x, so these system-created Watches would need to be modified in 7.x to remove the types field. Because doing such modifications as a secret background task could be risky, instead the 8.x Watch parser will tolerate and ignore an empty types array. It is clear that an empty types array can be considered identical to typeless. Non-empty types arrays will still be considered fatal errors in 8.x, as silently ignoring them could change the meaning of the search. Fixes #83235
In 6.x internal system components created Watches with an empty types array in their definition. Types do not exist in 8.x, so these system-created Watches would need to be modified in 7.x to remove the types field. Because doing such modifications as a secret background task could be risky, instead the 8.x Watch parser will tolerate and ignore an empty types array. It is clear that an empty types array can be considered identical to typeless. Non-empty types arrays will still be considered fatal errors in 8.x, as silently ignoring them could change the meaning of the search. Fixes #83235
Step to reproduce:
Observed:
Error:
Error loading watch could not parse [search] input for watch [ml-job3]. failed to parse [request]in es.log:
the watcher document:
The text was updated successfully, but these errors were encountered: