[Dataset Quality] Indicate if failure store isn't enabled for data stream

[rStelmach]

Added a tooltip and a link with documentation for Failed docs column when dataset does not have failure store enabled.

failed_docs_tooltip.mov

For now it awaits for the documentation PR to be merged : elastic/docs-content#1368

[yngrdyn]

/oblt-deploy

[yngrdyn]

Thanks for taking this one @rStelmach.
I have two main comments here:

1. I think we should change the approach here, from your changes I can infer that we are treating privileges (meaning user can not read failure store: read_failure_store) the same as a failure store not enabled for an specific dataStream. Take the following as an example (You can find everything configured in the PR deployment):

I've set up a custom component template enabling failure store for data streams following the pattern logs-foo-*

script

PUT _component_template/logs-foo@custom
{
  "template": {
    "data_stream_options": {
      "failure_store": {
        "enabled": true
      }
    }
  }
}

Then I ingested some documents in logs-foo-1 (Failure store enabled) and logs-bar-1 (Failure store disabled)

script

### Failure store enabled
POST logs-foo-1/_doc/1?op_type=create
{
  "foo": "bar"
}
POST logs-foo-1/_doc/2?op_type=create
{
  "foo": { "bar": 123}
}

#### Failure Store not enabled
POST logs-bar-1/_doc/1?op_type=create
{
  "foo": "bar"
}
POST logs-bar-1/_doc/2?op_type=create
{
  "foo": { "bar": 123}
}

User has proper privileges to read failure store over all datastreams following logs-* pattern

And this is what I see in dataset quality page

This is what I should be seeing

but I can only get to that state if the user doesn't have read privileges over failure store.

2. We should also consider what to do inside a specific dataStream in regards to failure Store, should we show something there (?) or instead we could use a banner at the top with a link to the specific documentation? (Something similar to what we do when user doesn't have privileges but now for enabling the failure store for the specific datastream)

@LucaWintergerst, @patpscal what are your thoughts on this one?

Note

I configured everything in the PR deployment, you can access with elastic, failure_store_some_enabled and failure_store_some_restricted with the same password generated by oblt-deploy command (🔒 deployment)

[yngrdyn]

We are missing some api tests (integration) asserting that we are getting the right information regarding failureStore being enabled/disabled

[LucaWintergerst]

@yngrdyn apologies for the super slow reply here - this is good, thank you work implementing it like this

[patpascal]

@patpscal is it ok to show the enablement as a warning? Should we treat it as an info instead?

I think we could treat that either way!

[yngrdyn]

This should also be translated

[yngrdyn]

/oblt-deploy

[yngrdyn]

Can we make this to look more like a link?

[yngrdyn]

Adding an icon would be beneficial here @patpscal?

[rStelmach]

How about this ?

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: f2bb67a

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
datasetQuality	418.5KB	420.3KB	+1.7KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
datasetQuality	23.8KB	24.1KB	+253.0B

History

• 💔 Build #311546 failed ed15c9a
• 💔 Build #311336 failed 1362929
• 💔 Build #310975 failed 66a42f1
• 💔 Build #310899 failed 77abd1c
• 💔 Build #310116 failed 257b60d
• 💔 Build #310013 failed 9f3fef1

[yngrdyn]

LGTM, thanks for taking this one
Good job 🚀

[kibanamachine]

Starting backport for target branches: 8.19

https://github.com/elastic/kibana/actions/runs/15844551689

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.19

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation