https://github.com/elastic/kibana/pull/168234 introduced a new part of the state used to generate the ID for the ML jobs for logs. This proved hard to test in an easy way so the tests introduced in that PR have been disabled.
Most likely the best solution to the issue is the refactor the state management used for the ML job IDs.
Rather than storing the ID format, the log view ID and the space ID and using those pieces to generate the ID in multiple places, we would store a full version of the ID or even the full ML job object and use that across the UI and the API requests.
Once that is done, the tests would need to be refactored but the same test cases should be easier to express in that world without having to rely on capturing network traffic.
https://github.com/elastic/kibana/pull/168234 introduced a new part of the state used to generate the ID for the ML jobs for logs. This proved hard to test in an easy way so the tests introduced in that PR have been disabled.
Most likely the best solution to the issue is the refactor the state management used for the ML job IDs. Rather than storing the ID format, the log view ID and the space ID and using those pieces to generate the ID in multiple places, we would store a full version of the ID or even the full ML job object and use that across the UI and the API requests.
Once that is done, the tests would need to be refactored but the same test cases should be easier to express in that world without having to rely on capturing network traffic.