Failing test: X-Pack Endpoint Integrations Functional Tests on ESS.x-pack/solutions/security/test/security_solution_endpoint/apps/integrations/artifact_entries_list·ts - integrations For each artifact list under management When on the Event Filters entries list should be able to add a new Event Filters entry

[kibanamachine]

A test failed on a tracked branch

Error: expected 'AND agent.ephemeral_idIS endpointendpoint' to equal 'AND agent.ephemeral_idIS endpoint'
    at Assertion.assert (expect.js:100:11)
    at Assertion.equal (expect.js:227:8)
    at Context.<anonymous> (artifact_entries_list.ts:235:80)
    at processTicksAndRejections (node:internal/process/task_queues:105:5)
    at Object.apply (wrap_function.js:74:16)

First failure: kibana-on-merge - 9.3

[elasticmachine]

Pinging @elastic/security-defend-workflows (Team:Defend Workflows)

[gergoabraham]

happened once, closing for cleanup

[kibanamachine]

New failure: kibana-on-merge - 9.4

[kibanamachine]

New failure: kibana-on-merge - main

[github-actions]

Likely test-design fix — double-input from retry in performActions produces endpointendpoint in artifact_entries_list.ts

The should be able to add a new Event Filters entry FTR test in x-pack/solutions/security/test/security_solution_endpoint/apps/integrations/artifact_entries_list.ts intermittently asserts on AND agent.ephemeral_idIS endpointendpoint instead of ...IS endpoint. The duplicated endpoint suffix matches exactly the input value defined for the valuesAutocompleteMatch combobox in mocks.ts:236, so the form field was typed twice. The performActions helper (artifact_entries_list.ts:154–161) calls testSubjects.setValue and then re-invokes it when the value attribute does not match — on an EuiComboBox (valuesAutocompleteMatch) the value attribute reflects the live search text, not the committed chip, so the retry fires routinely and the second setValue appends instead of replacing. The failure is recurrent across 9.3, 9.4, and main on the local kibana-on-merge pipeline. cc @szwarckonrad — your recent stabilization PR #268313 touched the same test for an unrelated symptom; the retry helper itself is the next thing to address.

Action: rewrite the input-retry block in performActions to drop the re-setValue (it is already retried inside setValue) or switch comboboxes to a chip-aware verification (e.g. read the rendered chip / use comboBox.setCustom), and re-run on the flaky-test runner.

• classification: test-design
• confidence: medium
• test.type: ftr
• test.file: x-pack/solutions/security/test/security_solution_endpoint/apps/integrations/artifact_entries_list.ts

Suspected root cause

• The error string expected 'AND agent.ephemeral_idIS endpointendpoint' to equal 'AND agent.ephemeral_idIS endpoint' shows the form value endpoint (defined in mocks.ts:236) was typed twice rather than once — direct evidence of compound input, not of a product-side concatenation.
• The performActions input branch calls setValue and then re-calls it when getAttribute('value') does not match (artifact_entries_list.ts:154–161). For EuiComboBox-backed inputs like valuesAutocompleteMatch, the DOM value attribute does not represent the committed selection, so the post-check trips even on success.
• testSubjects.setValue performs click → activeElement → clearValue → type (test_subjects.ts:275-296). Against a combobox where the previous value has been committed as a chip, clearValue (which clears the focused input field, not chips) does not remove the prior selection, so the second type('endpoint') appends rather than replaces.
• The failures recur on kibana-on-merge (a local target) across three branches with the same column (:80, the .equal(checkResult.value) call), which is consistent with intermittent timing of the combobox value-attribute read, not an environmental or product regression.

Key references

• Test file: artifact_entries_list.ts
• Latest failure: kibana-on-merge build 98225 (main)
• Related stabilization PR for the same test file: #268313 (commit 9248e30)

See full details

Full root-cause analysis

The failing assertion at artifact_entries_list.ts:235:80 (line numbering as of the failure stack — currently the equivalent assertion is the expect(...).to.equal(checkResult.value) at line 254–256) reads:

expected 'AND agent.ephemeral_idIS endpointendpoint' to equal 'AND agent.ephemeral_idIS endpoint'

The value endpoint is the form input defined for the Event Filters combobox value in mocks.ts:236, and the expected display string AND agent.ephemeral_idIS endpoint is the matching checkResults entry in mocks.ts:242. The rendered text shows the same literal endpoint concatenated with itself, with no whitespace and no IS separator between the two copies — meaning the duplication happened at the input level (the form submitted a single value endpointendpoint), not at the rendering layer.

The input is set by performActions in artifact_entries_list.ts:145–168:

} else if (formAction.type === 'input') {
  const newValue = (formAction.value || '') + (suffix ? suffix : '');
  await testSubjects.setValue(formAction.selector, newValue);
  await testSubjects.getAttribute(formAction.selector, 'value').then((value) => {
    if (value !== newValue) {
      return testSubjects.setValue(formAction.selector, newValue);
    }
  });
}

This post-set check is the weak point:

1. valuesAutocompleteMatch is an EuiComboBox (single-selection) for the Event Filters value field. Once a value is committed, the inner search input clears and the chosen option lives in a chip/badge, not in the DOM value attribute.
2. After the first setValue('endpoint') completes successfully and the option is committed, getAttribute('value') returns '' (or the residual search text), which does not equal 'endpoint', so the second setValue fires.
3. testSubjects.setValue does click → activeElement → clearValue → type (test_subjects.ts:275-296). clearValue clears the focused element (the inner combobox search input), but does not remove the existing committed chip. The next type('endpoint') then concatenates against the prior chip's text when the form is read back, producing the literal endpointendpoint.

The race is intermittent because whether the combobox has fully committed (and the search input has cleared) at the time of the getAttribute('value') check depends on browser/CI timing. On the more stable kibana-on-merge (local) pipeline, the test still fails roughly once per several months — consistent with a low-probability timing race rather than a hard product bug.

Recent history on the file shows targeted stabilizations (PR #268313 wrapped the post-create assertion in retry.waitForWithTimeout) but did not touch the performActions retry. The product code path (AND <field>IS <value> rendering of Event Filter criteria) has no recent regression that would explain the doubled value, and the input value is consistent with the test fixture, not a product-injected token.

Evidence used

• Failure stack from issue body and comments: build 84247 (9.3, 2025-12-18), build 94975 (9.4, 2026-04-21), build 98225 (main, 2026-05-22)
• Test file: artifact_entries_list.ts, particularly performActions lines 145–168 and the checkResults assertion lines 253–257
• Fixture data: mocks.ts Event Filters entry, lines 205–245
• setValue implementation: test_subjects.ts lines 275–296
• Related prior work on the same test: PR #268313 (stabilize 'add a new entry') / commit 9248e30, PR #261180 (unskip + reduce setup) / commit f21bf0e

Suggested patch

Drop the post-setValue value-check that re-invokes setValue on a combobox where the DOM value attribute is not the source of truth. testSubjects.setValue already wraps its body in retry.try, so explicit re-invocation is redundant and racy here.

--- a/x-pack/solutions/security/test/security_solution_endpoint/apps/integrations/artifact_entries_list.ts
+++ b/x-pack/solutions/security/test/security_solution_endpoint/apps/integrations/artifact_entries_list.ts
@@ -151,12 +151,7 @@
       for (const formAction of actions) {
         if (formAction.type === 'click') {
           await testSubjects.click(formAction.selector);
         } else if (formAction.type === 'input') {
           const newValue = (formAction.value || '') + (suffix ? suffix : '');
-          await testSubjects.setValue(formAction.selector, newValue);
-          await testSubjects.getAttribute(formAction.selector, 'value').then((value) => {
-            if (value !== newValue) {
-              return testSubjects.setValue(formAction.selector, newValue);
-            }
-          });
+          await testSubjects.setValue(formAction.selector, newValue);
         } else if (formAction.type === 'clear') {

If empirically the first set is too unreliable for the combobox fields, prefer using the comboBox service (getService('comboBox').setCustom(...)) for combobox-typed selectors instead of the manual double-setValue pattern — this commits via Enter and avoids re-typing entirely.

Generated by Failed Test Investigator for issue #246940 · ● 6.9M · ◷