[ML] Always enable next button in advanced job validation

[jgowdyelastic]

When validating an advanced job, if the validation results contain errors, the user should still be able to progress to the next step to create the job.
This will allow jobs t be created for indices which do not have any data, and so can fail field cardinality checks.

Relates to #78784

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials

[elasticmachine]

Pinging @elastic/ml-ui (:ml)

[walterra]

LGTM - Just a question on the structure: Since the code in validation.tsx already does the same check if the job type is advanced, could that also include the check if it's valid so that the callout component could be more "dumb" and don't do any checks by itself?

[jgowdyelastic]

LGTM - Just a question on the structure: Since the code in validation.tsx already does the same check if the job type is advanced, could that also include the check if it's valid so that the callout component could be more "dumb" and don't do any checks by itself?

I originally thought that the callout component should be written to be a little bit smart, so it would be reusable.
But thinking about it now, that is very unlikely, so i'll make this suggested change.

[sophiec20]

Should we be specifically handling the case where zero data points are found? Presumably this could be a warning validation.

Can we avoid the misleading message field blah is not an aggregatable field - unless it actually is not aggregatable, rather than not there.

[jgowdyelastic]

Should we be specifically handling the case where zero data points are found? Presumably this could be a warning validation.

Yes, we will need to enhance the job validation to check for this. Currently there is a limitation in the way the field cardinality check works in that any error thrown is reported as a field blah is not an aggregatable field failure.
This check should be smarter.

This PR has been added to "unblock" a user who runs into this limitation and to address the first checkbox in the original issue #78784
Further work will be needed to fix the check and improve the validation failure messaging, covered by the second checkbox in #78784

Alternatively we could park this PR and work on the second part. Which would hopefully mean this change wouldn't be needed. @peteharverson ?

Thinking about it more, I'm leaning towards abandoning this PR in favour of the larger change to the validation.

[peteharverson]

I agree with @jgowdyelastic that we should park this PR, and look at improving the validation to provide better messaging when there is no data, as well as allowing the user to progress through the advanced wizard even if validation fails.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: f816aa9

Metrics [docs]

@kbn/optimizer bundle module count

id	value	diff	baseline
ml	1186	+1	1185

async chunks size

id	value	diff	baseline
ml	10.5MB	+2.5KB	10.5MB

History

• 💚 Build #78238 succeeded f5af7b5

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[walterra]

This will be fixed in #86114.