Failing test: X-Pack Endpoint Integrations Functional Tests on Serverless.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 update an existing Event Filters entry

[kibanamachine]

A test failed on a tracked branch

Error: timed out waiting for entry is updated in list
    at onFailure (retry_for_truthy.ts:40:13)
    at retryForSuccess (retry_for_success.ts:91:7)
    at retryForTruthy (retry_for_truthy.ts:28:3)
    at RetryService.waitForWithTimeout (retry.ts:79:5)
    at Context.<anonymous> (artifact_entries_list.ts:260:11)
    at Object.apply (wrap_function.js:74:16)

First failure: kibana-on-merge - main

[elasticmachine]

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

[gergoabraham]

happened once, closing for cleanup

[kibanamachine]

New failure: kibana-on-merge - main

[github-actions]

Investigation Summary

The Event Filters "update an existing entry" FTR test (artifact_entries_list.ts) intermittently times out on Serverless waiting up to 20s for the EventFiltersListPage-card-criteriaConditions-condition card to render the updated text after submitting the edit flyout. Failures are very rare (Jan 5 2026 and May 14 2026 — twice in ~4 months on kibana-on-merge main), pointing to Serverless environment pressure rather than a product regression. The sibling create test in the same file had the same symptom and was already stabilized by extending its retry window in PR #268313.

Flakiness Finding

• classification: test
• confidence: medium

Suspected Root Cause

• The update flow uses retry.waitForWithTimeout('entry is updated in list', 20000, ...) to poll until the card's visible text equals testData.update.waitForValue ('AND agent.idIS test super large value' for Event Filters, per mocks.ts). 20s isn't always sufficient on a loaded Serverless runner — the flyout submit triggers a list re-fetch and re-render that can take longer.
• The sibling "add a new entry" test failed with the identical pattern on Serverless and was fixed only days before this latest failure by Konrad Szwarc's PR #268313 (commit message: "intermittently fails on Serverless with a TimeoutError waiting for the new artifact's criteriaConditions card to render"). cc @szwarckonrad — the update path appears to suffer from the same pressure-related slowness.
• Cadence (2 failures in 4+ months, first reporter @gergoabraham already closed once for cleanup) is consistent with environment flake, not a deterministic bug.
• The retry compares against fully-rendered text containing the freshly-typed value test super large value; if the list refresh is delayed past 20s, the card still shows the pre-update condition and the predicate never becomes true.
• Nothing in recent product code (artifact regrouping landed Apr 6 via #257001) changed the update submission path in a way that would explain a fresh regression here.

Proposed Fix

Mirror PR #268313 by extending the update retry budget (e.g. from 20s to 40s), and optionally wait for the flyout to actually close before polling — the submit button click returns immediately, so we can be polling the card text while the flyout is still open. Suggested edit in artifact_entries_list.ts:269-283:

         it(`should be able to update an existing ${testData.title} entry`, async () => {
           await endpointArtifactsTestResources.createArtifact(testData.listId, testData.createBody);
           await browser.refresh();
 
           await updateArtifact(testData, { policyId: policyInfo.packagePolicy.id });
 
+          // Ensure the edit flyout has actually closed before polling list contents
+          await testSubjects.waitForDeleted(`${testData.pagePrefix}-flyout-submitButton`);
+
           // Check edited artifact is in the list with new values (wait for list to be updated)
-          await retry.waitForWithTimeout('entry is updated in list', 20000, async () => {
+          await retry.waitForWithTimeout('entry is updated in list', 40000, async () => {
             const currentValue = await testSubjects.getVisibleText(
               `${testData.pagePrefix}-card-criteriaConditions${
                 testData.pagePrefix === 'EventFiltersListPage' ? '-condition' : ''
               }`
             );
             return currentValue === testData.update.waitForValue;
           });

If a follow-up confirms only the timeout was the issue, the waitForDeleted line can be dropped; bumping the retry alone matches the PR #268313 precedent.

Evidence Used

• Issue body and stack trace (timeout in retry_for_truthy.ts for predicate entry is updated in list).
• Comment history: @gergoabraham closed-for-cleanup on 2026-01-30; kibanamachine reported a second occurrence on 2026-05-14 (build kibana-on-merge Failing test: X-Pack API Integration Tests.x-pack/test/api_integration/apis/lens/existing_fields·ts - apis Lens existing_fields apis "before all" hook in "existing_fields apis" #97387).
• Test source: artifact_entries_list.ts lines 269-300.
• Mock data: mocks.ts line 291 (waitForValue: 'AND agent.idIS test super large value').
• Sibling fix: commit 9248e30 / PR #268313 by @szwarckonrad, landed 2026-05-11 — same Serverless timeout symptom on the create test in the same file.

Generated by Failed Test Investigator for issue #247872 · ● 1.1M · ◷

[kibanamachine]

New failure: kibana-on-merge - main