@camunda/e2e-test-suite 0.0.757 → 0.0.759

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

@@ -393,9 +393,32 @@ _curl_common() {
   # with a short backoff. Without this, brief network blips during long test
   # runs surface as empty responses (`<none>` status) and false-positive
   # FAILEDs in print_result. --max-time still bounds total time per attempt.
-  curl --http1.1 --max-time 30 --connect-timeout 10 \
-    --retry 3 --retry-delay 1 --retry-connrefused --retry-all-errors \
-    -i -s -H 'Expect:' "$@"
+  #
+  # 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).
+  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
+      printf '%s\n' "$gw_response"
+      return 0
+    fi
+    gw_attempt=$((gw_attempt + 1))
+    # Backoff 2,4,6,8,10,10,... capped at 10s -> ~90s total across 12 attempts.
+    sleep $(( gw_attempt < 5 ? gw_attempt * 2 : 10 ))
+  done
 }
 
 # Helper to get curl -F argument for tenantId in multipart forms

package/dist/tests/SM-8.9/mt-enabled-user-flows.spec.js

@@ -385,7 +385,8 @@ if (process.env.IS_MT === 'true') {
                 });
             }
         });
-        (0, SM_8_9_1.test)('User Can Be Assigned To Multiple Tenants @tasklistV2', async ({ page, modelerHomePage, modelerCreatePage, operateProcessInstancePage, operateProcessesPage, operateHomePage, navigationPage, managementIdentityTenantPage, connectorSettingsPage, connectorMarketplacePage, ocIdentityHomePage, ocTenantPage, managementIdentityPage, }) => {
+        // Skipped due to bug #320: https://github.com/camunda/marketplace-api/issues/320
+        SM_8_9_1.test.skip('User Can Be Assigned To Multiple Tenants @tasklistV2', async ({ page, modelerHomePage, modelerCreatePage, operateProcessInstancePage, operateProcessesPage, operateHomePage, navigationPage, managementIdentityTenantPage, connectorSettingsPage, connectorMarketplacePage, ocIdentityHomePage, ocTenantPage, managementIdentityPage, }) => {
             SM_8_9_1.test.slow();
             const randomString = await (0, _setup_1.generateRandomStringAsync)(3);
             const processName1 = 'Multiple_Tenant_Flow_1' + randomString;

package/package.json

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

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

@@ -393,9 +393,32 @@ _curl_common() {
   # with a short backoff. Without this, brief network blips during long test
   # runs surface as empty responses (`<none>` status) and false-positive
   # FAILEDs in print_result. --max-time still bounds total time per attempt.
-  curl --http1.1 --max-time 30 --connect-timeout 10 \
-    --retry 3 --retry-delay 1 --retry-connrefused --retry-all-errors \
-    -i -s -H 'Expect:' "$@"
+  #
+  # 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).
+  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
+      printf '%s\n' "$gw_response"
+      return 0
+    fi
+    gw_attempt=$((gw_attempt + 1))
+    # Backoff 2,4,6,8,10,10,... capped at 10s -> ~90s total across 12 attempts.
+    sleep $(( gw_attempt < 5 ? gw_attempt * 2 : 10 ))
+  done
 }
 
 # Helper to get curl -F argument for tenantId in multipart forms