[Data Quality] Integrate failure store modal

[SoniaSanzV]

Closes #231429

Summary

This PR integrates the Failure Store Modal in the Dataset Quality page.

failure_store.mov

Note: I'm not sure if there is a better way of refreshing the card after saving the failure store configs using the State Machine

[elasticmachine]

Pinging @elastic/kibana-management (Team:Kibana Management)

[SoniaSanzV]

I needed to change this to be able to include the failure store button. The component was a button itself, so I couldn't add a button inside of a button.

[ElenaStoeva]

Great job @SoniaSanzV! Tested locally and it looks good to me. Code changes also lgtm but will leave it up to @elastic/obs-ux-logs-team to review in more detail.

[yngrdyn]

Can we extend this work to also show the modal from the main page? Or maybe create an issue to handle it in a follow up PR?

Screen.Recording.2025-08-25.at.08.39.51.mov

[yngrdyn]

Not a blocker and not asking for this change in the current PR but I was expecting somehow the modal component handling the update by itself, in the current setup every consumer would need to create a route to actually enable the failure store and I'm guessing all the routes will be handled in the same way, all of them will call the same elasticsearch endpoint and configure the same properties there.

[SoniaSanzV]

@ElenaStoeva and I discussed that option, but in the end we decided would be better to let the modal stateful.

[yngrdyn]

What happens if customRetentionPeriod is undefined?
this would end up being:

# stateful
{
   ...
   lifecycle: {
      enabled: false
   }
}

#serverless
{
   ...
   lifecycle: {}
}

What does that mean in practice?

[SoniaSanzV]

If we set lifecycle enabled=false in serverless it would fail because lifecycle cannot be disabled in serverless. In the moment we add a data retention period, it would be set to enabled: true by ES.

{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "failures lifecycle cannot be disabled in serverless, please remove 'enabled=false'"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "failures lifecycle cannot be disabled in serverless, please remove 'enabled=false'"
  },
  "status": 400
}

But this is something that it's allowed in stateful, users can set a lifecycle data retention period but set it to enabled=false.

In practice, here, if failure store is disabled, the custom data retention would be undefined, so lifecycle would always be enabled=true when the user sets a custom retention period

[yngrdyn]

but not having a customRetentionPeriod, if failure store is enabled, means that the defaultRetention will be used?

[SoniaSanzV]

If the failure store is enabled, yes

[yngrdyn]

Thanks for the details, now I have a better understanding

[SoniaSanzV]

I misunderstood this, I've created a PR for fixing it #233292

[yngrdyn]

This works beautifully (I tested locally for stateful and serverless) :chefs-kiss:

Screen.Recording.2025-08-26.at.10.21.11.mov

Then when I checked the settings of the dataStream

Good job @SoniaSanzV 🚀

[afharo]

kibana.jsonc LGTM

[yngrdyn]

instead of changing the test I'd prefer we change the route code
If dataStreamDetails is empty then return empty, otherwise append the defaultRetentionPeriod
Maybe we would have other implications in the UI if dataStreamDetails only contains the defaultRetentionPeriod

[SoniaSanzV]

instead of changing the test I'd prefer we change the route code If dataStreamDetails is empty then return empty, otherwise append the defaultRetentionPeriod Maybe we would have other implications in the UI if dataStreamDetails only contains the defaultRetentionPeriod

Makes total sense, changed in da179b3

[yngrdyn]

Thanks for the changes

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: da179b3

Failed CI Steps

• FTR Configs #36

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
datasetQuality	819	826	+7

Async chunks

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

id	before	after	diff
datasetQuality	424.2KB	431.9KB	+7.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	24.2KB	24.5KB	+315.0B

History

• 💔 Build #332338 failed 28d1a82
• 💔 Build #332307 failed 28ba986
• 💚 Build #331680 succeeded 409330c
• 💔 Build #330906 failed aa01085
• 💔 Build #330309 failed 0a53bf1

cc @SoniaSanzV