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
#43767 moved indexer_state into checkpointing.next, and it has been pointed out that this means it is only available when a checkpoint is in progress.
From an end user perspective the difference between task_state and indexer_state is an internal implementation detail. But for debugging purposes we might want to see it even when there isn't a checkpoint in progress. If we move it to the top level then as an end user I'm back to wondering which of task_state and indexer_state I should be taking notice of, and why there are two states in the first place. A better alternative is to have just one top level state that combines the two, like anomaly detection jobs and datafeeds have. It can be defined as:
failed if what's currently reported as task_state is failed
stopped if there is no persistent task
Otherwise what's currently reported as indexer_state
To avoid multiple breaking changes to the stats format in consecutive versions and complex BWC this change should be made for 7.4.
The text was updated successfully, but these errors were encountered:
This commit replaces task_state and indexer_state in the
data frame _stats output with a single top level state
that combines the two. It is defined as:
- failed if what's currently reported as task_state is failed
- stopped if there is no persistent task
- Otherwise what's currently reported as indexer_state
Closeselastic#45201
This commit replaces task_state and indexer_state in the
data frame _stats output with a single top level state
that combines the two. It is defined as:
- failed if what's currently reported as task_state is failed
- stopped if there is no persistent task
- Otherwise what's currently reported as indexer_state
Closes#45201
#43767 moved
indexer_state
intocheckpointing.next
, and it has been pointed out that this means it is only available when a checkpoint is in progress.From an end user perspective the difference between
task_state
andindexer_state
is an internal implementation detail. But for debugging purposes we might want to see it even when there isn't a checkpoint in progress. If we move it to the top level then as an end user I'm back to wondering which oftask_state
andindexer_state
I should be taking notice of, and why there are two states in the first place. A better alternative is to have just one top level state that combines the two, like anomaly detection jobs and datafeeds have. It can be defined as:failed
if what's currently reported astask_state
isfailed
stopped
if there is no persistent taskindexer_state
To avoid multiple breaking changes to the stats format in consecutive versions and complex BWC this change should be made for 7.4.
The text was updated successfully, but these errors were encountered: