[Automatic Migrations] Clear migration completion toast notification on navigation

[kqualters-elastic]

Summary

issue: #237466

This pr changes the way migration service classes call toasts so that they can be dismissed as well when a user navigates to the migration table upon completion.

clear_toast.mov

Checklist

• Unit or functional tests were updated or added to match the most common scenarios
• The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines
• Review the backport guidelines and apply applicable backport:* labels.

[elasticmachine]

Pinging @elastic/security-threat-hunting-investigations (Team:Threat Hunting:Investigations)

[e40pud]

I'm curious how these type of toasts are handled

Those usually are closed when user clicks the "See the full error" action button.

If we proceed with your approach, I would prefer to put toast management logic (save, remove etc.) inside the common SiemMigrationsServiceBase class where we call the function to show it. This way we do not change much in other places and will just need to return toast itself and pass some onDismissToast callback.

Also, I noticed that these changes do not handle the situation when user clicks the toast dismiss/close button (X) and when the toast goes away because of the toastLifeTimeMs. The ToastInput has onClose handler which I believe we will need to use to cleanup toasts.

[logeekal]

I don't like that toast identity is only communicated after it has been raised but for raising we need the ID of the toast so that we can remove it later. But we cannot do anything about the core design of the toasts plugin. On the top of that managing toasts feels like an overkill for this.

If we have manage toasts, we should rather create a separate state in useAppToast or a new ToastManager.

Also, I think current approach intermingles siem_migrations with toasts a little too much. What do you think about below approach. I moved the capability of raising and removing toast to notifications.ts. I think this preserves separation of concerns. It seems to be working well also. I have raised a small PR with suggested changes : kqualters-elastic#9.

See if makes sense and if it passed your tests.

Screen.Recording.2025-10-15.at.12.30.40.mov

[kqualters-elastic]

I don't like that toast identity is only communicated after it has been raised but for raising we need the ID of the toast so that we can remove it later. But we cannot do anything about the core design of the toasts plugin. On the top of that managing toasts feels like an overkill for this.

If we have manage toasts, we should rather create a separate state in useAppToast or a new ToastManager.

Also, I think current approach intermingles siem_migrations with toasts a little too much. What do you think about below approach. I moved the capability of raising and removing toast to notifications.ts. I think this preserves separation of concerns. It seems to be working well also. I have raised a small PR with suggested changes : kqualters-elastic#9.

See if makes sense and if it passed your tests.

Screen.Recording.2025-10-15.at.12.30.40.mov

This is much better, will go with this.

[logeekal]

Desk Tested. Working great. Thanks 🚀 .

[kibanamachine]

Starting backport for target branches: 9.2

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

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 5a9f26f

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
securitySolution	11.0MB	11.0MB	+144.0B

History

• 💔 Build #356795 failed 89c08fb
• 💔 Build #356746 failed 505d404
• 💚 Build #351520 succeeded 76f1f2a
• 💔 Build #351491 failed d03e403
• 💔 Build #351482 failed 5735b77

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	9.2

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

Questions ?

Please refer to the Backport tool documentation