@camunda/e2e-test-suite 0.0.1104 → 0.0.1106

package/dist/pages/8.8/ClusterDetailsPage.d.ts

@@ -22,6 +22,7 @@ declare class ClusterDetailsPage {
     readonly clientCredentialsDialog: Locator;
     readonly clustersLink: Locator;
     readonly alertsTab: Locator;
+    readonly activeTabPanel: Locator;
     readonly alertsList: Locator;
     readonly createFirstAlertButton: Locator;
     readonly createNewAlertButton: Locator;

package/dist/pages/8.8/ClusterDetailsPage.js

@@ -28,6 +28,7 @@ class ClusterDetailsPage {
     clientCredentialsDialog;
     clustersLink;
     alertsTab;
+    activeTabPanel;
     alertsList;
     createFirstAlertButton;
     createNewAlertButton;
@@ -105,7 +106,14 @@ class ClusterDetailsPage {
             .getByRole('banner')
             .getByRole('link', { name: 'Clusters' });
         this.alertsTab = page.getByRole('tab', { name: 'Alerts' });
-        this.alertsList = page
+        // Only the selected tab's panel is rendered without `hidden`, so this always
+        // resolves to the tab currently on screen. Scoping the alert rows to it is
+        // what stops `alertsList` from silently counting a different tab's table:
+        // unscoped, `getByRole('row')` matched the Overview tab's 15-row "Cluster
+        // Details" list whenever the Alerts tab was not the active one, so the
+        // "alerts are gone" assertion was reporting rows that were never alerts.
+        this.activeTabPanel = page.locator('[role="tabpanel"]:not([hidden])');
+        this.alertsList = this.activeTabPanel
             .getByRole('row')
             .filter({ hasNotText: 'Delivery method' }); //Filter out header row
         this.createFirstAlertButton = page.getByRole('button', {
@@ -362,7 +370,26 @@ class ClusterDetailsPage {
     }
     async clickAlertsTab() {
         await (0, test_1.expect)(this.alertsTab).toBeVisible({ timeout: 40000 });
-        await this.alertsTab.click();
+        // The cluster details page re-mounts while its data finishes loading: the
+        // nightly trace shows the DOM emptied out at the exact moment of this click,
+        // and once the app re-rendered the tab strip was back on its default
+        // "Overview" tab with the click discarded. Nothing downstream noticed, so
+        // the alert steps ran against the Overview tab. Re-drive the click until the
+        // tab reports itself selected.
+        await (0, test_1.expect)(async () => {
+            const selected = await this.alertsTab.getAttribute('aria-selected');
+            if (selected !== 'true') {
+                await this.alertsTab.click({ timeout: 30000 });
+            }
+            await (0, test_1.expect)(this.alertsTab).toHaveAttribute('aria-selected', 'true', {
+                timeout: 10000,
+            });
+        }).toPass({ timeout: 90000 });
+        // Wait for the panel to finish loading before the caller reads the list.
+        // Exactly one of these renders: "Create an alert" is the empty state,
+        // "Create new alert" sits above a populated table. Without this the callers
+        // can observe an empty, still-loading panel and mistake it for "no alerts".
+        await (0, test_1.expect)(this.createFirstAlertButton.or(this.createNewAlertButton).first()).toBeVisible({ timeout: 60000 });
     }
     async clickExpandButton() {
         await this.expandButton.click({ timeout: 60000 });

package/dist/pages/8.8/ModelerCreatePage.js

@@ -1393,24 +1393,42 @@ class ModelerCreatePage {
         //   1. Connect cluster → "Configure environment" modal → select cluster → Save
         //   2. Deploy process → wait for success banner
         //   3. Configure test case
+        // camunda-hub 8b4226983e (#28226, 2026-09-04) turned the three setup steps
+        // into a Carbon Accordion, so the Deploy button now lives in the "Deploy
+        // process" item's *content*, a sibling of the heading -- scoping by the
+        // heading text's parent can no longer reach it. Anchor on the test id the
+        // hub's own e2e suite uses (test-studio/e2e/pages/Definition.ts), keeping
+        // the text-scoped locator as a fallback for pre-accordion builds.
         const setupDeployButton = this.page
+            .getByTestId('test-configuration-deploy-button')
+            .or(this.page
             .getByText('Deploy process')
             .locator('..')
-            .getByRole('button', { name: 'Deploy' });
+            .getByRole('button', { name: 'Deploy' }))
+            .first();
         // Both attributes on this button have been renamed by camunda-hub, in
         // separate commits: a90fd06 changed the label from "Configure scenario" to
         // "Configure test case", and b3958a1649 (#27259, 2026-08-07) then changed
         // the test id from `play-configuration-configure-scenario-button` to
         // `configure-test-case-button`. Match current test id, then pre-rename test
-        // id, then either label, so a further rename of any single attribute cannot
-        // break the step.
+        // id. The label-based fallback that used to follow them had to go: the
+        // accordion's third heading is itself a <button> labelled "Configure test
+        // case", rendered `disabled={!isConfigureReady}` (camunda-hub
+        // test-studio/src/test-mode/test-configuration-panel/TestConfigurationPanel.tsx).
+        // The regex matched that heading, so the "already deployed?" probe below saw
+        // it, skipped the deploy step outright, and then clicked a permanently
+        // disabled button until the step timed out.
         const configureScenarioButton = this.page
             .getByTestId('configure-test-case-button')
             .or(this.page.getByTestId('play-configuration-configure-scenario-button'))
-            .or(this.page.getByRole('button', {
-            name: /^Configure (test case|scenario)$/,
-        }))
             .first();
+        // Step 2 is an accordion item too, and its content (the Deploy button)
+        // only renders visibly while that item is expanded. It expands by itself
+        // once the cluster step completes, but a manual heading click is the
+        // recovery path if it did not.
+        const deployStepHeading = this.page.getByRole('button', {
+            name: 'Deploy process',
+        });
         // Play settles into exactly ONE of three states, and which one is not
         // knowable up front, so race them instead of timing out on each in turn:
         // the setup overlay, the legacy Continue button, or the configure-test
@@ -1496,25 +1514,91 @@ class ModelerCreatePage {
             // 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.
+            //
+            // Deploy is done when the step swaps its button for the success badge --
+            // camunda-hub DeployStepContent.tsx renders
+            // `data-testid="deploy-success-badge"` reading "Successfully deployed";
+            // the old "Process has been successfully deployed" banner is gone, so keep
+            // it only as a fallback for older builds. Probing for a Configure control
+            // alone is not enough: current builds render none at all until the deploy
+            // step completes.
+            const deploySuccessBadge = this.page
+                .getByTestId('deploy-success-badge')
+                .or(this.page.getByText('Process has been successfully deployed'))
+                .first();
+            // `deploy-success-badge` on its own is NOT a usable "is the deploy done"
+            // probe. DeployStepContent renders it inside the "Deploy process"
+            // accordion item, and TestConfigurationPanel collapses that item the
+            // instant the deploy finishes (`isDeployStepComplete` ->
+            // `hideConfigurationOverlay()` -> `isDeployOpen` false). Carbon keeps a
+            // collapsed accordion's content mounted, so the badge stays in the DOM
+            // but never becomes visible again -- confirmed in a failing nightly
+            // trace (PR #3339, 8.9), whose call log shows the badge resolving 89
+            // times in a row and reading "hidden" every time. DeployStepIcon
+            // carries the same state in the accordion *heading*, which stays on
+            // screen while the item is collapsed, and the configure panel only
+            // opens once the deploy step completes, so treat any of the three as
+            // proof.
+            const deployCompleteIcon = this.page.locator('[aria-label="Deployment complete"]');
+            const isDeployComplete = async () => (await deployCompleteIcon.isVisible().catch(() => false)) ||
+                (await deploySuccessBadge.isVisible().catch(() => false)) ||
+                (await configureTestPanel.isVisible().catch(() => false));
             const alreadyDeployed = await configureScenarioButton
-                .isVisible({ timeout: 3000 })
+                .isEnabled({ timeout: 3000 })
                 .catch(() => false);
-            if (!alreadyDeployed) {
-                // Step 2: deploy — wait for enabled; button stays disabled until the cluster
+            if (!alreadyDeployed && !(await isDeployComplete())) {
+                // The Deploy button lives inside the "Deploy process" accordion item,
+                // which expands itself once the cluster step completes. Nudge the
+                // heading if it is still collapsed, otherwise the button is present
+                // but hidden and the click below would time out.
+                const deployButtonShown = await setupDeployButton
+                    .isVisible({ timeout: 30000 })
+                    .catch(() => false);
+                if (!deployButtonShown) {
+                    const canExpandDeployStep = await deployStepHeading
+                        .isEnabled({ timeout: 5000 })
+                        .catch(() => false);
+                    if (canExpandDeployStep) {
+                        await deployStepHeading.click({ timeout });
+                    }
+                }
+                // Wait for enabled; the 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)(this.page.getByText('Process has been successfully deployed')).toBeVisible({ timeout: 90000 });
+                await (0, test_1.expect)(setupDeployButton).toBeEnabled({ timeout: 60000 });
+                // The click is retried against the completion probe rather than fired
+                // once, because the same collapse re-renders the accordion around the
+                // button: it can detach mid-click, which is the second nightly
+                // symptom. A re-click can only happen while the deploy is provably
+                // still incomplete AND the button is enabled -- a deploy in flight
+                // disables it and a finished deploy replaces it with the badge, so
+                // this cannot double-deploy. If the deploy never completes the loop
+                // still fails.
+                await (0, test_1.expect)(async () => {
+                    if (await isDeployComplete()) {
+                        return;
+                    }
+                    const canClick = (await setupDeployButton.isVisible().catch(() => false)) &&
+                        (await setupDeployButton.isEnabled().catch(() => false));
+                    if (canClick) {
+                        await setupDeployButton.click({ timeout });
+                    }
+                    (0, test_1.expect)(await isDeployComplete()).toBe(true);
+                }).toPass({ timeout: 120000, intervals: [1000, 2000, 5000] });
             }
-            // Step 3: leave the overlay, and confirm we actually left it. The
-            // button only calls hideConfigurationOverlay(); the overlay's own
-            // cluster-change effect can then fire resetDeployment and bring it
-            // straight back, and ConfigureTestPanel stays null while it is up.
-            // Assert the panel really rendered, and re-drive the click if the
-            // overlay returned.
+            // Step 3: the configure-test-case step opens on its own once the deploy
+            // step completes (TestConfigurationPanel hides the setup overlay in an
+            // effect keyed on isDeployStepComplete). Wait for the panel that step
+            // renders; only if it stays closed -- e.g. the panel's own
+            // cluster-change effect fired resetDeployment and reopened setup -- fall
+            // back to clicking the step heading, which by then is enabled.
             await (0, test_1.expect)(async () => {
-                if (await configurationOverlay.isVisible()) {
-                    await configureScenarioButton.click({ timeout });
+                if (!(await configureTestPanel.isVisible())) {
+                    const canOpenConfigureStep = await configureScenarioButton
+                        .isEnabled({ timeout: 5000 })
+                        .catch(() => false);
+                    if (canOpenConfigureStep) {
+                        await configureScenarioButton.click({ timeout: 15000 });
+                    }
                 }
                 await (0, test_1.expect)(configureTestPanel).toBeVisible({ timeout: 15000 });
             }).toPass({ timeout: 90000 });

package/dist/pages/8.9/AppsPage.js

@@ -29,7 +29,15 @@ class AppsPage {
         this.appSwitcherButton = page.getByLabel('App Switcher');
         this.tasklistLink = page.getByRole('link', { name: 'Tasklist', exact: true });
         this.adminLink = page.getByRole('link', { name: /^(Admin|Identity)$/ });
-        this.operateLink = page.getByRole('link', { name: 'Operate', exact: true });
+        // Console renders its OWN "Operate" nav link pointing at
+        // /org/<id>/appTeaser/operate — the "Create a cluster to use Operate"
+        // teaser page, not a cluster's Operate. It carries the same role and
+        // accessible name as the app switcher's cluster-scoped Operate link, so an
+        // unfiltered locator silently navigates to the teaser and every downstream
+        // Operate assertion then fails on a Console page. Match only the real link.
+        this.operateLink = page
+            .getByRole('link', { name: 'Operate', exact: true })
+            .and(page.locator('a:not([href*="appTeaser"])'));
         this.optimizeLink = page.getByRole('link', { name: 'Optimize', exact: true });
         this.consoleLink = page.getByRole('link', { name: 'Console', exact: true });
         this.camundaComponentsButton = page.getByLabel('Camunda components');
@@ -84,7 +92,15 @@ class AppsPage {
             }
             catch (error) {
                 console.warn(`Click attempt ${retries + 1} failed: ${error}`);
-                await new Promise((resolve) => setTimeout(resolve, 10000));
+                // The app-switcher panel can open with no entries at all when the
+                // request that populates it fails (the nightly trace shows the panel
+                // open and empty, with its backing requests erroring out). Re-clicking
+                // the switcher only toggles that same empty panel shut, so the retries
+                // could never recover. Reload first so the panel is rebuilt from a
+                // fresh fetch — the same recovery clickOperate/clickTasklist/clickAdmin
+                // already use.
+                await this.page.waitForLoadState('domcontentloaded');
+                await this.page.reload();
             }
         }
         throw new Error(`Failed to click the modeler link after ${maxRetries} attempts.`);

package/dist/pages/8.9/ClusterPage.js

@@ -192,8 +192,17 @@ class ClusterPage {
     }
     async clickClusterNameInput() {
         await (0, clickLocatorWithRetry_1.clickLocatorWithRetry)(this.page, this.clusterNameInput, {
+            visibilityTimeout: 30000,
+            totalTimeout: 120000,
             postAction: async () => {
+                // Going back to the Clusters list is not a recovery on its own: the
+                // create-cluster form is a separate route, so the name input can never
+                // reappear until "Create new cluster" is pressed again. The nightly
+                // trace shows the form's `clusters/parameters` request failing, which
+                // left the form empty, and every retry then waited on an input that was
+                // no longer reachable. Re-open the form so the request is retried.
                 await this.clickClusterBanner();
+                await this.clickCreateNewClusterButton();
             },
         });
     }

package/dist/pages/8.9/ModelerCreatePage.js

@@ -1334,10 +1334,36 @@ class ModelerCreatePage {
         //   1. Connect cluster → "Configure environment" modal → select cluster → Save
         //   2. Deploy process → wait for success banner
         //   3. Configure test case
+        // The Deploy button lives in the accordion item's *content* panel, a
+        // sibling of the "Deploy process" heading -- not inside it -- so the
+        // label-scoped locator below resolves to nothing on current builds. The
+        // "Test Studio" rebrand gave the button the stable test id
+        // `test-configuration-deploy-button` (camunda-hub
+        // `frontend/packages/modeler/test-studio/src/test-mode/configuration-overlay/DeployStepContent.tsx`).
+        // Prefer it, and keep the label-scoped locator as a fallback for older
+        // modeler builds that render the button without a test id.
         const setupDeployButton = this.page
+            .getByTestId('test-configuration-deploy-button')
+            .or(this.page
             .getByText('Deploy process')
             .locator('..')
-            .getByRole('button', { name: 'Deploy' });
+            .getByRole('button', { name: 'Deploy' }))
+            .first();
+        // Deploy completion signal. camunda-hub 8b4226983e (#28226, 2026-09-04)
+        // replaced the overlay's "Process has been successfully deployed." status
+        // text with a badge carrying `deploy-success-badge`; keep the old sentence
+        // as a fallback for modeler builds from before that commit.
+        const deploySuccessBadge = this.page
+            .getByTestId('deploy-success-badge')
+            .or(this.page.getByText('Process has been successfully deployed'))
+            .first();
+        // Step 2 is an accordion item too, and its content (the Deploy button)
+        // only renders visibly while that item is expanded. It expands by itself
+        // once the cluster step completes, but a manual heading click is the
+        // recovery path if it did not.
+        const deployStepHeading = this.page.getByRole('button', {
+            name: 'Deploy process',
+        });
         // Both attributes on this button have been renamed by camunda-hub, in
         // separate commits: a90fd06 changed the label from "Configure scenario" to
         // "Configure test case", and b3958a1649 (#27259, 2026-08-07) then changed
@@ -1437,25 +1463,85 @@ class ModelerCreatePage {
             // 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.
+            // The "Configure test case" accordion header is always rendered once the
+            // overlay is up -- TestConfigurationPanel renders it whenever
+            // canShowConfigureSection and only sets `disabled={!isConfigureReady}` --
+            // so isVisible() alone is always true here. Gating on it skipped Step 2
+            // even while deploy was still pending, and Step 3 then burned its whole
+            // budget clicking a permanently disabled button. Gate on isEnabled().
             const alreadyDeployed = await configureScenarioButton
-                .isVisible({ timeout: 3000 })
+                .isEnabled({ timeout: 3000 })
                 .catch(() => false);
-            if (!alreadyDeployed) {
-                // Step 2: deploy — wait for enabled; button stays disabled until the cluster
+            // `deploy-success-badge` on its own is NOT a usable "is the deploy done"
+            // probe. DeployStepContent renders it inside the "Deploy process"
+            // accordion item, and TestConfigurationPanel collapses that item the
+            // instant the deploy finishes (`isDeployStepComplete` ->
+            // `hideConfigurationOverlay()` -> `isDeployOpen` false). Carbon keeps a
+            // collapsed accordion's content mounted, so the badge stays in the DOM
+            // but never becomes visible again -- confirmed in a failing nightly
+            // trace, whose call log shows the badge resolving 89 times in a row and
+            // reading "hidden" every time. DeployStepIcon carries the same state in
+            // the accordion *heading*, which stays on screen while the item is
+            // collapsed, and the configure panel only opens once the deploy step
+            // completes, so treat any of the three as proof.
+            const deployCompleteIcon = this.page.locator('[aria-label="Deployment complete"]');
+            const isDeployComplete = async () => (await deployCompleteIcon.isVisible().catch(() => false)) ||
+                (await deploySuccessBadge.isVisible().catch(() => false)) ||
+                (await configureTestPanel.isVisible().catch(() => false));
+            if (!alreadyDeployed && !(await isDeployComplete())) {
+                // The Deploy button lives inside the "Deploy process" accordion item,
+                // which expands itself once the cluster step completes. Nudge the
+                // heading if it is still collapsed, otherwise the button is present
+                // but hidden and the click below would time out.
+                const deployButtonShown = await setupDeployButton
+                    .isVisible({ timeout: 30000 })
+                    .catch(() => false);
+                if (!deployButtonShown) {
+                    const canExpandDeployStep = await deployStepHeading
+                        .isEnabled({ timeout: 5000 })
+                        .catch(() => false);
+                    if (canExpandDeployStep) {
+                        await deployStepHeading.click({ timeout });
+                    }
+                }
+                // Wait for enabled; the 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)(this.page.getByText('Process has been successfully deployed')).toBeVisible({ timeout: 90000 });
+                await (0, test_1.expect)(setupDeployButton).toBeEnabled({ timeout: 60000 });
+                // The click is retried against the completion probe rather than fired
+                // once, because the same collapse re-renders the accordion around the
+                // button: it can detach mid-click, which is the second nightly
+                // symptom (a stuck-hidden badge, or the later Start button never
+                // rendering because deploy silently never landed). A re-click can
+                // only happen while the deploy is provably still incomplete AND the
+                // button is enabled -- a deploy in flight disables it and a finished
+                // deploy replaces it with the badge, so this cannot double-deploy. If
+                // the deploy never completes the loop still fails.
+                await (0, test_1.expect)(async () => {
+                    if (await isDeployComplete()) {
+                        return;
+                    }
+                    const canClick = (await setupDeployButton.isVisible().catch(() => false)) &&
+                        (await setupDeployButton.isEnabled().catch(() => false));
+                    if (canClick) {
+                        await setupDeployButton.click({ timeout });
+                    }
+                    (0, test_1.expect)(await isDeployComplete()).toBe(true);
+                }).toPass({ timeout: 120000, intervals: [1000, 2000, 5000] });
             }
-            // Step 3: leave the overlay, and confirm we actually left it. The
-            // button only calls hideConfigurationOverlay(); the overlay's own
-            // cluster-change effect can then fire resetDeployment and bring it
-            // straight back, and ConfigureTestPanel stays null while it is up.
-            // Assert the panel really rendered, and re-drive the click if the
-            // overlay returned.
+            // Step 3: the configure-test-case step opens on its own once the deploy
+            // step completes (TestConfigurationPanel hides the setup overlay in an
+            // effect keyed on isDeployStepComplete). Wait for the panel that step
+            // renders; only if it stays closed -- e.g. the panel's own
+            // cluster-change effect fired resetDeployment and reopened setup -- fall
+            // back to clicking the step heading, which by then is enabled.
             await (0, test_1.expect)(async () => {
-                if (await configurationOverlay.isVisible()) {
-                    await configureScenarioButton.click({ timeout });
+                if (!(await configureTestPanel.isVisible())) {
+                    const canOpenConfigureStep = await configureScenarioButton
+                        .isEnabled({ timeout: 5000 })
+                        .catch(() => false);
+                    if (canOpenConfigureStep) {
+                        await configureScenarioButton.click({ timeout: 15000 });
+                    }
                 }
                 await (0, test_1.expect)(configureTestPanel).toBeVisible({ timeout: 15000 });
             }).toPass({ timeout: 90000 });

package/dist/tests/8.9/orchestration-cluster-mcp-server/mcp-cluster-tools.spec.js

@@ -55,6 +55,11 @@ _8_9_1.test.describe('Orchestration Cluster MCP Server - Cluster Tools @tasklist
             _8_9_1.test.slow();
             await _8_9_1.test.step('Navigate to completed process in Operate', async () => {
                 await homePage.clickClusters();
+                // clickOperate expects the app switcher to already be open: its
+                // first attempt looks for the switcher's Operate entry, which does
+                // not exist on the Clusters page, so it always burned an attempt
+                // before recovering. Open it first, as every other spec does.
+                await appsPage.clickCamundaApps();
                 await appsPage.clickOperate(clusterName);
                 await (0, test_1.expect)(operateHomePage.operateBanner).toBeVisible({
                     timeout: 60000,

package/dist/tests/8.9/orchestration-cluster-mcp-server/mcp-user-task-tools.spec.js

@@ -108,6 +108,11 @@ _8_9_1.test.describe('Orchestration Cluster MCP Server - User Task Tools @taskli
             await _8_9_1.test.step('Navigate to completed process in Operate', async () => {
                 await page.goto('/');
                 await homePage.clickClusters();
+                // clickOperate expects the app switcher to already be open: its
+                // first attempt looks for the switcher's Operate entry, which does
+                // not exist on the Clusters page, so it always burned an attempt
+                // before recovering. Open it first, as every other spec does.
+                await appsPage.clickCamundaApps();
                 await appsPage.clickOperate(clusterName);
                 await (0, test_1.expect)(operateHomePage.operateBanner).toBeVisible({
                     timeout: 60000,

package/package.json

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