if there is a risk onChange might be undefined, it might be safer to wrap this in a check.

There is an issue with the types provided by import type { CustomComponentProps } from '@elastic/eui/src/components/search_bar/filters/custom_component_filter';. onChange is always defined in this case.

In other places in the notifications page inference is used.
I wonder if we're introducing confusion by using the label Trained models in this menu, even though it's probably clearer and we used Trained model everywhere else in the UI.
It's a shame the notifications use inference as the type.

Not asking for a change here, just thinking out loud.

Agree, it's indeed confusing. Everywhere in the UI code, I refer to this as trained models.
On the data level for the .ml-notifications* it's inference, hence I decided to keep it this way. If I'm not mistaken it's the only exception in the user-facing labels so far.

Is this component limited to working with notifications only? If not, could it be moved to the top-level components folder?

I presume this is the only use case for this component, so I'd rather keep it as is for now.

OK! We can always move it at a later date when we find another use case for it.

Entities that had notifications, but have since been deleted, cannot be selected. Is there a way to populate it with all entities that have had notifications?

Note that I hadn't synchronized the saved objects for the gallery_delete job here. Therefore the old saved object for this job still existed. Do you think we should be showing notifications for a deleted job in this case @jgowdyelastic ?

Not sure it's possible, because of the space awareness. It'd require an extra API call to retrieve all unique terms for job_id from .ml-notifications*, but eventually, we won't be able to resolve what IDs are available for the user (because Kibana saved objects are already deleted).

I think the alternative is too tricky to implement. We'd have to check every job to see whether it does still exist.
Just to clarify what's happening here...
When a job is deleted, it happens in the background in es, Kibana does not know when the job has actually been deleted so we can't be sure when to delete the saved object.
It was decided that leaving these orphaned saved objects behind was not a problem. They are deleted on sync or when a new job arrives with the same name.

The reason gallery_delete is showing up here is because the saved object still exists.
IMO the behaviour here is ok. It's not ideal, but the alternative of checking whether a job really still exists before listing its messages would add an overhead.