You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The UnusedStateRemover only checks which jobs exist by looking in the cluster state. It deletes state documents that do not correspond to a job that exists. Therefore, following the move to storing job configurations in an index it will delete all model state for such jobs each night, leaving them unable to be reopened if they are closed before another background persist is performed.
The UnusedStateRemover needs to be changed to consider jobs in both cluster state and indices. (This basically means it should get the jobs list via the job manager - the problem is very similar to the one fixed in #36936.)
The text was updated successfully, but these errors were encountered:
The unused state remover was never adjusted to account for jobs stored
in the config index. The result was that when triggered it removed
state for all jobs stored in the config index.
This commit fixes the issue.
Closeselastic#37109
The unused state remover was never adjusted to account for jobs stored
in the config index. The result was that when triggered it removed
state for all jobs stored in the config index.
This commit fixes the issue.
Closes#37109
The unused state remover was never adjusted to account for jobs stored
in the config index. The result was that when triggered it removed
state for all jobs stored in the config index.
This commit fixes the issue.
Closes#37109
The
UnusedStateRemover
only checks which jobs exist by looking in the cluster state. It deletes state documents that do not correspond to a job that exists. Therefore, following the move to storing job configurations in an index it will delete all model state for such jobs each night, leaving them unable to be reopened if they are closed before another background persist is performed.The
UnusedStateRemover
needs to be changed to consider jobs in both cluster state and indices. (This basically means it should get the jobs list via the job manager - the problem is very similar to the one fixed in #36936.)The text was updated successfully, but these errors were encountered: