API question: find split for given config entity

I checked the referenced issue and I have given it some thought. But unfortunately I don't have a solution.
The best I can think of is to use the export storage and copy that to the configured location. That will have the things split out that config split wants to split out, including to its collections inside of the export storage.

Other modules should not try to replicate the splitting config split is doing. That said config split doesn't write the config to the split forlder while splitting, but instead to a temporary storage and then writes it to the split forlder only when the drush config export command succeeds. In other words there is already a "dry run" splitting and we could just check all the temporary storages to see if the config you are looking for is there...

Thanks @bircher for explaining some of the details. Unfortunately, that doesn't help in my use case, where the config auto export → module is writing changed config entities on the fly to a working directory from where they get later processed by an async background process, e.g. to push them to the git repository of the website to keep track of config changes on a live site.

This is working great even when config split is in place, as we scan the split directories for the changed config entity and find out that way, where it belongs to.

Where it fails, though, as described in the related issue 📌 Config split error Active , is when the changed config entity doesn't exist yet in the file system. Then, this method is missing the fact that it belongs to one of the splits. A dry-run, as suggested, would theoretically work around that, but it feels like a huge overhead.

But I can now see, why there isn't an API call that tells me what I'm looking for, since only a full process may be able to determine that. Pretty unfortunate, but maybe the best we can get.

Well, what you can do is cache the dry run.
But I don't know if that doesn't get you into trouble later. Because some config gets patched. But also, theoretically at least, things could change depending on the content of the config that gets changed. And of course there are also other modules that do fun stuff with config exports (I maintain also config ignore, but there are others too)

Thanks @bircher for all your considerations. Looks like we can't provide the functionality that was requested in the related issue. But the reporter stated there, this isn't a show stopper, so we won't spend any more time on this for now.

Automatically closed - issue fixed for 2 weeks with no activity.