@camunda/e2e-test-suite 0.0.1164 → 0.0.1166

package/dist/pages/8.10/ModelerCreatePage.js

@@ -1546,10 +1546,36 @@ class ModelerCreatePage {
             // deciding, then branch:
             //   - "Connect cluster" button visible → no cluster connected, connect one
             //   - Deploy button enabled            → a cluster is already connected
-            //   - deploy success badge visible     → re-entering an already deployed
+            //   - deploy already complete          → re-entering an already deployed
             //     process application, where the Deploy button is replaced by the
-            //     badge and "Connect cluster" by "Change", so neither of the first
-            //     two states is ever reached
+            //     deploy step's completion state and "Connect cluster" by "Change",
+            //     so neither of the first two states is ever reached
+            //
+            // The success badge is NOT a usable completion signal, not even by
+            // attachment: the current Test Studio panel does not render it at all,
+            // so a wait on it can never resolve — that is what made step 2 below
+            // burn its whole 90s budget on every 8.10 nightly from 2026-09-10 on,
+            // while the same flow stayed green on 8.9 and SM-8.10, both of which
+            // already probe the panel instead. The deploy step reports completion
+            // three other ways: the "Deployment complete" icon in the accordion
+            // HEADING (which stays on screen when the item collapses), the
+            // "Configure test case" step unlocking, and the configure-test panel
+            // opening. Accept any of them, keep the badge for older modeler builds.
+            // A failed deploy leaves all four absent, so both the settle wait and
+            // step 2 still fail on a real deploy failure rather than masking it.
+            //
+            // This probe has to be shared with the settle wait, not just used in
+            // step 2: the already-deployed state is exactly the one that renders no
+            // "Connect cluster" button and no enabled Deploy button, so a settle
+            // wait keyed on the badge alone can never see it and would throw here
+            // before step 2 is ever reached.
+            const deployCompleteIcon = this.page.locator('[aria-label="Deployment complete"]');
+            const isDeployComplete = async () => (await isDeployReported()) ||
+                (await deployCompleteIcon.isVisible().catch(() => false)) ||
+                (await configureTestPanel.isVisible().catch(() => false)) ||
+                (await configureScenarioButton
+                    .isEnabled({ timeout: 3000 })
+                    .catch(() => false));
             const connectClusterButton = this.page.getByRole('button', {
                 name: 'Connect cluster',
             });
@@ -1560,8 +1586,11 @@ class ModelerCreatePage {
                 const deployEnabled = await setupDeployButton
                     .isEnabled()
                     .catch(() => false);
-                const deployDone = await isDeployReported();
-                (0, test_1.expect)(connectVisible || deployEnabled || deployDone).toBe(true);
+                // Evaluated last and only when needed: its isEnabled() probe waits on
+                // a button that is absent on most builds, so short-circuiting keeps
+                // the common "Deploy is enabled" poll cheap.
+                const settled = connectVisible || deployEnabled || (await isDeployComplete());
+                (0, test_1.expect)(settled).toBe(true);
             }).toPass({ timeout: 30000 });
             const needsClusterConnect = await connectClusterButton
                 .isVisible()
@@ -1602,17 +1631,16 @@ class ModelerCreatePage {
             // deploy step complete. checkExistingDeployment only runs when
             // processApplicationId is defined, which it now is, so re-entering
             // Play on an already-deployed process application legitimately
-            // has nothing to deploy and renders no Deploy button at all.
-            const alreadyDeployed = (await isDeployReported()) ||
-                (await configureScenarioButton
-                    .isEnabled({ timeout: 3000 })
-                    .catch(() => false));
-            if (!alreadyDeployed) {
+            // has nothing to deploy and renders no Deploy button at all. Keyed on
+            // the shared completion probe defined above, never on the success badge.
+            if (!(await isDeployComplete())) {
                 // Step 2: deploy — wait for enabled; button stays disabled until the cluster
                 // connection is confirmed by the backend after the Save in step 1.
                 await (0, test_1.expect)(setupDeployButton).toBeEnabled({ timeout: 30000 });
                 await setupDeployButton.click({ timeout });
-                await (0, test_1.expect)(deploySuccessBadge).toBeAttached({ timeout: 90000 });
+                await (0, test_1.expect)(async () => {
+                    (0, test_1.expect)(await isDeployComplete()).toBe(true);
+                }).toPass({ timeout: 90000, intervals: [1000, 2000, 5000] });
             }
             // Step 3: reach the configure-test panel and confirm it really rendered.
             // The accordion panel opens step 3 on its own once the deploy step

package/dist/resources/test-api-v2-complete.sh

@@ -394,24 +394,31 @@ _curl_common() {
   # runs surface as empty responses (`<none>` status) and false-positive
   # FAILEDs in print_result. --max-time still bounds total time per attempt.
   #
-  # Outer gateway-retry loop: an nginx `502 Bad Gateway` / `504 Gateway
-  # Timeout` (or an empty/no-status response) is emitted by the ingress when
-  # it cannot reach the upstream orchestration REST API — e.g. while an
-  # orchestration pod is rolling during an upgrade-minor run. That is never a
-  # valid response to any assertion in this suite (the API returns JSON status
-  # bodies, never a bare nginx HTML page), so re-issue the whole request with
-  # capped backoff to ride out a brief upstream restart window. curl's own
-  # --retry budget (~4s) is too small for a pod restart; this widens it to
-  # ~90s. A sustained outage still returns the real 502/504 once the budget is
-  # exhausted, so it surfaces as a genuine FAILED (not masked).
+  # Outer gateway-retry loop: an nginx `502 Bad Gateway` / `503 Service
+  # Temporarily Unavailable` / `504 Gateway Timeout` (or an empty/no-status
+  # response) is emitted by the ingress when it cannot reach the upstream
+  # orchestration REST API — 502/504 when an upstream is reachable but not
+  # answering, 503 when the ingress has no ready endpoint at all (every
+  # orchestration pod unready, e.g. while a pod is rolling during an
+  # upgrade-minor run or while probes fail under the load this suite
+  # generates). Such a response is never a valid answer to any assertion in
+  # this suite (the API returns JSON status bodies, never a bare nginx HTML
+  # page), so re-issue the whole request with capped backoff to ride out a
+  # brief upstream restart window. curl's own --retry budget (~4s) is too
+  # small for a pod restart; this widens it to ~90s. A sustained outage still
+  # returns the real 502/503/504 once the budget is exhausted, so it surfaces
+  # as a genuine FAILED (not masked).
   local gw_attempt=0 gw_max=12 gw_response gw_status
   while :; do
     gw_response="$(curl --http1.1 --max-time 30 --connect-timeout 10 \
       --retry 3 --retry-delay 1 --retry-connrefused --retry-all-errors \
       -i -s -H 'Expect:' "$@")"
     gw_status="$(echo "$gw_response" | grep -m1 -E '^HTTP/[0-9.]+' | awk '{print $2}' || true)"
-    if { [[ "$gw_status" != "502" && "$gw_status" != "504" && -n "$gw_status" ]]; } \
-        || (( gw_attempt >= gw_max )); then
+    if { [[ -n "$gw_status" && "$gw_status" != "502" \
+            && "$gw_status" != "503" && "$gw_status" != "504" ]] \
+         || { [[ "$gw_status" == "503" \
+                 && "$gw_response" != *'<center>nginx</center>'* ]]; } \
+         || (( gw_attempt >= gw_max )); then
       printf '%s\n' "$gw_response"
       return 0
     fi

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@camunda/e2e-test-suite",
-  "version": "0.0.1164",
+  "version": "0.0.1166",
   "description": "End-to-end test helpers for Camunda 8",
   "repository": {
     "type": "git",

package/resources/test-api-v2-complete.sh

@@ -394,24 +394,31 @@ _curl_common() {
   # runs surface as empty responses (`<none>` status) and false-positive
   # FAILEDs in print_result. --max-time still bounds total time per attempt.
   #
-  # Outer gateway-retry loop: an nginx `502 Bad Gateway` / `504 Gateway
-  # Timeout` (or an empty/no-status response) is emitted by the ingress when
-  # it cannot reach the upstream orchestration REST API — e.g. while an
-  # orchestration pod is rolling during an upgrade-minor run. That is never a
-  # valid response to any assertion in this suite (the API returns JSON status
-  # bodies, never a bare nginx HTML page), so re-issue the whole request with
-  # capped backoff to ride out a brief upstream restart window. curl's own
-  # --retry budget (~4s) is too small for a pod restart; this widens it to
-  # ~90s. A sustained outage still returns the real 502/504 once the budget is
-  # exhausted, so it surfaces as a genuine FAILED (not masked).
+  # Outer gateway-retry loop: an nginx `502 Bad Gateway` / `503 Service
+  # Temporarily Unavailable` / `504 Gateway Timeout` (or an empty/no-status
+  # response) is emitted by the ingress when it cannot reach the upstream
+  # orchestration REST API — 502/504 when an upstream is reachable but not
+  # answering, 503 when the ingress has no ready endpoint at all (every
+  # orchestration pod unready, e.g. while a pod is rolling during an
+  # upgrade-minor run or while probes fail under the load this suite
+  # generates). Such a response is never a valid answer to any assertion in
+  # this suite (the API returns JSON status bodies, never a bare nginx HTML
+  # page), so re-issue the whole request with capped backoff to ride out a
+  # brief upstream restart window. curl's own --retry budget (~4s) is too
+  # small for a pod restart; this widens it to ~90s. A sustained outage still
+  # returns the real 502/503/504 once the budget is exhausted, so it surfaces
+  # as a genuine FAILED (not masked).
   local gw_attempt=0 gw_max=12 gw_response gw_status
   while :; do
     gw_response="$(curl --http1.1 --max-time 30 --connect-timeout 10 \
       --retry 3 --retry-delay 1 --retry-connrefused --retry-all-errors \
       -i -s -H 'Expect:' "$@")"
     gw_status="$(echo "$gw_response" | grep -m1 -E '^HTTP/[0-9.]+' | awk '{print $2}' || true)"
-    if { [[ "$gw_status" != "502" && "$gw_status" != "504" && -n "$gw_status" ]]; } \
-        || (( gw_attempt >= gw_max )); then
+    if { [[ -n "$gw_status" && "$gw_status" != "502" \
+            && "$gw_status" != "503" && "$gw_status" != "504" ]] \
+         || { [[ "$gw_status" == "503" \
+                 && "$gw_response" != *'<center>nginx</center>'* ]]; } \
+         || (( gw_attempt >= gw_max )); then
       printf '%s\n' "$gw_response"
       return 0
     fi