@camunda/e2e-test-suite 0.0.1165 → 0.0.1167

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/pages/8.9/Authorization.js

@@ -105,10 +105,21 @@ class Authorization {
                 force: true,
             });
         }
-        await this.createAuthorizationSubmitButton.click();
-        await (0, test_1.expect)(this.createAuthorizationModal).not.toBeVisible({
-            timeout: 30000,
-        });
+        // Submitting POSTs to the orchestration cluster's Identity API, which
+        // answers 503 while the cluster is still settling. Carbon then leaves the
+        // modal open with the form still filled, so the only thing the old
+        // single-shot submit could do was wait out its 30s and fail. Re-submitting
+        // replays the same request from the same form rather than building a
+        // second authorization; the guard keeps a slow-but-successful close from
+        // clicking a button that is already gone.
+        await (0, test_1.expect)(async () => {
+            if (await this.createAuthorizationModal.isVisible()) {
+                await this.createAuthorizationSubmitButton.click();
+            }
+            await (0, test_1.expect)(this.createAuthorizationModal).not.toBeVisible({
+                timeout: 30000,
+            });
+        }).toPass({ timeout: 150000, intervals: [5000, 10000, 15000] });
         await this.selectResourceTypeTab(authorization.resourceType).click();
         const item = this.page.getByRole('row').filter({
             hasText: `${authorization.ownerId}${authorization.resourceId}`,

package/dist/pages/8.9/ModelerCreatePage.js

@@ -382,6 +382,19 @@ class ModelerCreatePage {
         if (processId.length > 0) {
             await this.clickStartEventElement();
             await this.clickGeneralPropertiesPanel();
+            // Renaming the file is what normally propagates the name into
+            // `bpmn:process@name`, but when the rename lands while the just-created
+            // diagram is still initialising the sync is lost and the process keeps
+            // the template default "New BPMN diagram" -- the breadcrumb shows the new
+            // name while the properties panel still shows the old one. That name is
+            // the label Tasklist prints under each task (the user task itself is
+            // unnamed, so its row reads `Activity_<id>` / `New BPMN diagram`), so
+            // `openTask(processName)` then waits out its whole budget on a task that
+            // is sitting right there under the wrong label. Set the process name
+            // explicitly: the panel is already open on the process element for the id
+            // edit below, so this costs one extra fill and removes the race.
+            await this.clickNameInput();
+            await this.fillNamedInput(processName);
             await this.clickIdInput();
             await this.fillIdInput(processId);
             await this.clickStartEventElement();

package/dist/pages/8.9/OperateProcessInstancePage.js

@@ -49,8 +49,15 @@ class OperateProcessInstancePage {
         await this.page.reload();
     }
     async closePopOverIfVisible() {
+        // This is the first thing every caller does on a freshly opened Operate
+        // popup, so the wait has to cover the whole SSO hand-off (weblogin ->
+        // sso-callback -> deep link) before the instance header renders, not just
+        // the render itself. 60s did not: the first attempt of the 8.9 nightly's
+        // "Form.js Integration with User Task and AI Generated Form" died here
+        // (run 34919774298). Aligned with the 180s the callers already allow for
+        // the instance-state assertions that immediately follow this call.
         await (0, test_1.expect)(this.page.getByText('Instance History').first()).toBeVisible({
-            timeout: 60000,
+            timeout: 180000,
         });
         if (await this.whatsNewPopUp.isVisible()) {
             await this.gotItButton.click();

package/dist/pages/8.9/TaskDetailsPage.js

@@ -91,7 +91,16 @@ class TaskDetailsPage {
         this.decrementButton = page.getByRole('button', { name: 'Decrement' });
         this.dateInput = page.getByLabel('Date of Birth');
         this.timeInput = page.getByPlaceholder('hh:mm ?m');
-        this.checkbox = this.form.getByLabel('Agree');
+        // Only used by the AI-generated-form flow, where the form is produced by a
+        // model from a free-text prompt asking for "a Checkbox with the label
+        // Agree". The model paraphrases: the same prompt has rendered both `Agree`
+        // and `I confirm the details are correct.`. Prefer the requested label and
+        // fall back to the form's checkbox input, which is the field the prompt
+        // asks for either way.
+        this.checkbox = this.form
+            .getByLabel('Agree')
+            .or(this.form.locator('input[type="checkbox"]'))
+            .first();
         this.selectDropdown = this.form.getByText('Select').last();
         this.tagList = page.getByPlaceholder('Search');
         this.detailsInfo = page.getByTestId('details-info');
@@ -181,7 +190,14 @@ class TaskDetailsPage {
         await this.page.getByText(time).click();
     }
     async checkCheckbox() {
-        await this.checkbox.check();
+        // form-js re-renders the whole form on every value change, so a click that
+        // lands while the preceding field's re-render is in flight focuses the
+        // checkbox without toggling it ("Clicking the checkbox did not change its
+        // state"). `check()` already verifies the resulting state, so retrying it
+        // is enough -- the assertion stays exactly as strict.
+        await (0, test_1.expect)(async () => {
+            await this.checkbox.check({ timeout: 10000 });
+        }).toPass({ timeout: 60000, intervals: [1000, 2000, 5000] });
     }
     async selectDropdownValue(value) {
         await this.selectDropdown.click();

package/dist/tests/8.9/rba-enabled-v2-user-flows.spec.js

@@ -74,7 +74,7 @@ _8_9_1.test.describe.parallel('RBA Enabled User Flows Test @tasklistV2', () => {
                 sessionStorage.clear();
             });
             await page.goto('/');
-            await loginPage.loginWithTestUser(testUser);
+            await (0, UtilitiesPage_1.loginWithRetry)(page, loginPage, testUser, 1000);
         });
         await _8_9_1.test.step('Navigate to Web Modeler', async () => {
             await appsPage.clickCamundaApps();
@@ -112,7 +112,7 @@ _8_9_1.test.describe.parallel('RBA Enabled User Flows Test @tasklistV2', () => {
                 sessionStorage.clear();
             });
             await page.goto('/');
-            await loginPage.loginWithTestUser(testUser);
+            await (0, UtilitiesPage_1.loginWithRetry)(page, loginPage, testUser, 1000);
         });
         await _8_9_1.test.step('Navigate to Tasklist and Make Sure that the Two Deployed Processes Are Not Accessible', async () => {
             await appsPage.clickCamundaApps();
@@ -189,7 +189,7 @@ _8_9_1.test.describe.parallel('RBA Enabled User Flows Test @tasklistV2', () => {
             await page.goto('/');
         });
         await _8_9_1.test.step('Login as Test User', async () => {
-            await loginPage.loginWithTestUser(testUser);
+            await (0, UtilitiesPage_1.loginWithRetry)(page, loginPage, testUser, 1000);
         });
         await _8_9_1.test.step('Navigate to Web Modeler', async () => {
             await appsPage.clickCamundaApps();
@@ -227,7 +227,7 @@ _8_9_1.test.describe.parallel('RBA Enabled User Flows Test @tasklistV2', () => {
                 sessionStorage.clear();
             });
             await page.goto('/');
-            await loginPage.loginWithTestUser(testUser);
+            await (0, UtilitiesPage_1.loginWithRetry)(page, loginPage, testUser, 1000);
         });
         await _8_9_1.test.step('Navigate to Tasklist and Only First Process Is Accessible', async () => {
             await appsPage.clickCamundaApps();
@@ -406,7 +406,7 @@ _8_9_1.test.describe.parallel('RBA Enabled User Flows Test @tasklistV2', () => {
                 sessionStorage.clear();
             });
             await page.goto('/');
-            await loginPage.loginWithTestUser(testUser);
+            await (0, UtilitiesPage_1.loginWithRetry)(page, loginPage, testUser, 1000);
         });
         await _8_9_1.test.step('Navigate to Web Modeler', async () => {
             await appsPage.clickCamundaApps();

package/package.json

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