test(cypress): wait for the S3 CRUD delete requests instead of stale page-load runs

[wyattwalter]

Description

S3_1_spec.js test 6 generates a CRUD page on the shared S3 test bucket, searches for the file it created, deletes it through the page's delete modal, and asserts the delete succeeded with two cy.wait("@postExecute") calls. That alias is registered once for the whole spec, so the waits yield the oldest execute request nobody has waited on, not the two requests Confirm fires.

Generating the page fires the page-load ListFiles twice (page load, then the layout update that follows); the spec waits for one. Typing the search prefix fires a third. Confirm fires DeleteFile and then a prefixed ListFiles from its success callback. The first post-Confirm wait therefore yields the second page-load ListFiles, which lists the whole bucket with an empty prefix. In every failing log that request had timed out at the 10 s default (PE-QRY-5000, EXECUTE_PLUGIN_ACTION_ERROR, isPageLoad: true, HTTP 200 with isExecutionSuccess: false). The delete itself had succeeded.

This change registers a fresh intercept alias immediately before Confirm and waits on it twice, so the two existing assertions land on DeleteFile and the refresh ListFiles. No assertion is relaxed; the test now checks the delete it triggered.

Evidence, first-attempt logs of the scheduled release image test

Three retry events in three runs, same test, same failing command (assert expected false to equal true on response.body.data.isExecutionSuccess right after wait @postExecute):

• CE run 35552022891 (2026-09-21), shard 54, position 14 of 19, recovered on repeat 2
• CE run 36083074819 (2026-09-25), shard 38, position 2 of 14, recovered on repeat 2
• EE run 36083583207 (2026-09-25), shard 13, position 2 of 14, repeat 2; repeat 1 failed test 1 on the same full-bucket LIST timing out

The full-bucket LIST exceeding 10 s is a property of the shared test bucket and is raised separately. This PR removes the spec's dependence on that request; it does not make the LIST faster, so test 1 can still hit the timeout on its own query. No red-before repro is possible on demand for an external timing condition, so the evidence is the three logs above.

Call sites checked

The same "Confirm, then wait on the shared execute alias" pattern exists in GenerateCRUD/MongoURI_Spec.ts and GenerateCRUD/Postgres2_Spec.ts. Both run against database plugins whose page-load queries return quickly and both assert only the HTTP status, so they are not affected by this failure mode and are left unchanged.

Fixes https://linear.app/appsmith/issue/APP-16023

Automation

/ok-to-test tags="@tag.All"

🤖 Generated with Claude Code

Tip

🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉
Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/36120402437
Commit: 8a27846
Cypress dashboard.
Tags: @tag.All
Spec:

---

Fri, 25 Sep 2026 10:41:42 UTC

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

_{Comment @coderabbitai help to get the list of available commands.}

[linear-code]

APP-16023