@camunda/e2e-test-suite 0.0.1203 → 0.0.1205

package/dist/pages/8.10/AppsPage.d.ts

@@ -31,7 +31,7 @@ declare class AppsPage {
     clickCluster(component: Locator, name: string): Promise<void>;
     clickModeler(): Promise<void>;
     private isModelerAuthTransit;
-    openModelerWithRetry(banner: Locator, timeout?: number, maxRetries?: number): Promise<void>;
+    openModelerWithRetry(banner: Locator, timeout?: number, maxRetries?: number, ready?: Locator): Promise<void>;
     openOperateWithRetry(banner: Locator, clusterName: string, timeout?: number, maxRetries?: number): Promise<void>;
     clickTasklist(clusterName: string): Promise<void>;
     openTasklistWithRetry(banner: Locator, clusterName: string, timeout?: number, maxRetries?: number): Promise<void>;

package/dist/pages/8.10/AppsPage.js

@@ -220,12 +220,34 @@ class AppsPage {
     // URL and the Modeler banner never renders. Reloading cannot recover it —
     // the `code` is single use — so re-enter through the Camunda apps menu,
     // which starts a fresh handshake.
-    async openModelerWithRetry(banner, timeout = 60000, maxRetries = 3) {
+    //
+    // `ready` is an optional second gate for callers that need proof of a
+    // Modeler SESSION rather than proof of the Modeler shell. The banner is not
+    // that proof -- Modeler renders it on its own login page too -- and the
+    // hand-off can still fail after the shell is up: when
+    // `POST /api/internal/login` returns 500, hub's
+    // auth-service.handleRedirectCallback() falls into its catch and calls
+    // logout(), bouncing the tab through Auth0's /v2/logout back to
+    // `modeler.<host>/login` about half a minute AFTER the banner became
+    // visible. The banner assertion passes in that window, the spec then hunts
+    // for its project tile on a login screen, and the failure surfaces minutes
+    // later and nowhere near its cause ("Failed to click locator
+    // getByTitle('Cross Component Test Project') ... after N attempts"). Pass
+    // something only an authenticated Modeler renders -- the projects list's
+    // create button -- and a logged-out tab is caught here instead, where the
+    // retry re-runs the handshake and with it the internal login.
+    async openModelerWithRetry(banner, timeout = 60000, maxRetries = 3, ready) {
+        const modelerReady = async () => {
+            await (0, test_1.expect)(banner).toBeVisible({ timeout });
+            if (ready) {
+                await (0, test_1.expect)(ready).toBeVisible({ timeout });
+            }
+        };
         for (let attempt = 0; attempt < maxRetries; attempt++) {
             await this.clickCamundaApps();
             await this.clickModeler();
             try {
-                await (0, test_1.expect)(banner).toBeVisible({ timeout });
+                await modelerReady();
                 return;
             }
             catch (error) {
@@ -244,7 +266,7 @@ class AppsPage {
                 // falls through to the re-entry below exactly as before.
                 if (this.isModelerAuthTransit()) {
                     try {
-                        await (0, test_1.expect)(banner).toBeVisible({ timeout });
+                        await modelerReady();
                         return;
                     }
                     catch (settleError) {

package/dist/pages/8.10/FormJsPage.js

@@ -74,19 +74,27 @@ class FormJsPage {
         // toast never renders even though generation finished, leaving the old
         // single 5-minute wait stuck until the test timed out. Re-attempt on a
         // reloaded editor (fresh websocket) if the toast doesn't arrive.
+        //
+        // Submitting the request is retried on the same reloaded editor, not just
+        // the toast: the generator panel is mounted by the button click, and a
+        // click that does not open it leaves every following step acting on a
+        // surface that is not there -- reported as `locator.click: Timeout
+        // 10000ms exceeded ... waiting for getByPlaceholder('A form for an
+        // american standard loan request')`. That used to escape the loop on the
+        // first attempt because only the toast wait was guarded.
         const maxAttempts = 2;
         for (let attempt = 1; attempt <= maxAttempts; attempt++) {
-            await (0, test_1.expect)(this.aiFormGeneratorButton).toBeVisible({
-                timeout: 90000,
-            });
-            await this.clickAIFormGeneratorButton();
-            await this.clickFormRequestInput();
-            await this.fillFormRequestInput(request);
-            await this.clickGenerateFormButton();
-            await (0, test_1.expect)(this.page.getByText('Generating...'))
-                .toBeVisible({ timeout: 60000 })
-                .catch(() => { });
             try {
+                await (0, test_1.expect)(this.aiFormGeneratorButton).toBeVisible({
+                    timeout: 90000,
+                });
+                await this.clickAIFormGeneratorButton();
+                await this.clickFormRequestInput();
+                await this.fillFormRequestInput(request);
+                await this.clickGenerateFormButton();
+                await (0, test_1.expect)(this.page.getByText('Generating...'))
+                    .toBeVisible({ timeout: 60000 })
+                    .catch(() => { });
                 await (0, test_1.expect)(this.page.getByText('Successfully generated smart form.')).toBeVisible({ timeout: 180000 });
                 await (0, sleep_1.sleep)(60000);
                 return;
@@ -102,8 +110,12 @@ class FormJsPage {
     async clickAIFormGeneratorButton() {
         await this.aiFormGeneratorButton.click();
     }
+    // The generator panel slides in after its button click and renders this
+    // input with it, so the inherited 10s actionTimeout is raced against a panel
+    // that is still mounting -- every other control on this page allows 60s.
     async clickFormRequestInput() {
-        await this.formRequestInput.click();
+        await (0, test_1.expect)(this.formRequestInput).toBeVisible({ timeout: 60000 });
+        await this.formRequestInput.click({ timeout: 60000 });
     }
     async fillFormRequestInput(formRequest) {
         await this.formRequestInput.fill(formRequest);
@@ -243,7 +255,11 @@ class FormJsPage {
         }
         await this.selectOnlyThisResource();
         await this.clickDeploySubButton();
-        await (0, test_1.expect)(this.deploySuccessNotification).toBeVisible({ timeout: 30000 });
+        // Deploying the form is a round trip through the cluster, so the toast is
+        // gated on the cluster's response rather than on the modal closing. 30s is
+        // the shortest wait in this flow and the one the nightly ran out of; the
+        // rest of the page object budgets 60-90s for cluster-bound waits.
+        await (0, test_1.expect)(this.deploySuccessNotification).toBeVisible({ timeout: 90000 });
     }
 }
 exports.FormJsPage = FormJsPage;

package/dist/pages/8.10/ModelerCreatePage.d.ts

@@ -114,6 +114,9 @@ declare class ModelerCreatePage {
     clickSecondDeployButton(): Promise<void>;
     modelJobWorkerDiagram(processName: string, embedFrom?: boolean, processId?: string): Promise<void>;
     private waitForDiagramEditorToLoad;
+    private onModelerLoginPage;
+    private waitForModelerSession;
+    private linkFormToUserTask;
     modelCamundaUserTaskDiagram(processName: string, processId?: string, formName?: string): Promise<void>;
     assignToCandidateGroup(taskName: string, candidateGroup: string, assignee?: string): Promise<void>;
     assignToCandidateUser(taskName: string, candidateUser: string, assignee?: string): Promise<void>;

package/dist/pages/8.10/ModelerCreatePage.js

@@ -409,11 +409,91 @@ class ModelerCreatePage {
                 if (attempt === maxAttempts - 1) {
                     throw error;
                 }
+                // A reload cannot bring the editor back while the tab is mid-logout
+                // bounce -- it only restarts it -- so let hub finish returning to the
+                // diagram first, and reload only if it never does.
+                if (await this.waitForModelerSession()) {
+                    continue;
+                }
                 console.warn(`Diagram editor did not load on attempt ${attempt + 1}; reloading.`);
                 await this.page.reload();
             }
         }
     }
+    // True while the tab is sitting on Modeler's own login surface rather than in
+    // the app. Hub can throw a modelling session out mid-flow: when a request
+    // comes back 401 -- or the late `POST /api/internal/login` 500 that
+    // `AppsPage.openModelerWithRetry` guards the hand-off against lands after
+    // entry has already been cleared -- auth-service calls logout() and the tab
+    // is bounced to `modeler.<host>/login?returnUrl=<the diagram>`.
+    onModelerLoginPage(url = this.page.url()) {
+        try {
+            const { hostname, pathname } = new URL(url);
+            return (hostname.startsWith('modeler.') &&
+                /^\/login(-callback)?\/?$/.test(pathname));
+        }
+        catch {
+            // Not a parsable URL yet (e.g. a tab still on about:blank).
+            return false;
+        }
+    }
+    // Waits out that bounce. The IdP session itself is still alive, so hub
+    // completes the round trip on its own and comes back to the diagram named in
+    // returnUrl -- but anything issued in the meantime waits out its whole
+    // timeout against a login screen instead, which is how linking a form
+    // reported `locator.click: Timeout 90000ms exceeded ... navigated to
+    // https://modeler.<host>/login?returnUrl=%2Fdiagrams%2F...`. Reports whether
+    // the tab made it back, so a caller can redo what the sign-out interrupted.
+    async waitForModelerSession(timeout = 120000) {
+        if (!this.onModelerLoginPage()) {
+            return false;
+        }
+        return await this.page
+            .waitForURL((url) => !this.onModelerLoginPage(url.toString()), { timeout })
+            .then(() => true)
+            .catch(() => false);
+    }
+    // Links `formName` to the selected user task, redoing the link when the tab
+    // is signed out while it is in flight. The picker is a modal on the diagram
+    // page, so the logout bounce takes it down with the page: once hub has
+    // returned to the diagram the whole link has to be driven again, not just
+    // the click that was interrupted. The element stays selected across the
+    // round trip -- its id travels in the returnUrl -- so the properties panel
+    // comes back with the "Link form" control in place. Watched via
+    // `framenavigated` rather than by re-reading the URL afterwards, because the
+    // bounce can finish inside the failing click's own timeout and leave nothing
+    // behind to detect.
+    async linkFormToUserTask(formName) {
+        let signedOutMidFlow = false;
+        const watchForSignOut = (frame) => {
+            if (frame === this.page.mainFrame() &&
+                this.onModelerLoginPage(frame.url())) {
+                signedOutMidFlow = true;
+            }
+        };
+        this.page.on('framenavigated', watchForSignOut);
+        try {
+            await this.clickEmbedFormButton();
+            await this.clickForm(formName);
+            await this.clickEmbedButton();
+            return;
+        }
+        catch (error) {
+            if (!signedOutMidFlow) {
+                throw error;
+            }
+            console.warn('Session was dropped while linking the form; waiting for Modeler to ' +
+                'come back and linking again.');
+            await this.waitForModelerSession();
+        }
+        finally {
+            this.page.off('framenavigated', watchForSignOut);
+        }
+        await this.waitForDiagramEditorToLoad();
+        await this.clickEmbedFormButton();
+        await this.clickForm(formName);
+        await this.clickEmbedButton();
+    }
     async modelCamundaUserTaskDiagram(processName, processId = '', formName = '') {
         await this.waitForDiagramEditorToLoad();
         await this.enterDiagramName(processName);
@@ -445,9 +525,7 @@ class ModelerCreatePage {
         await this.clickUserTaskOption();
         await this.assertImplementationOption('zeebeUserTask');
         if (formName.length > 0) {
-            await this.clickEmbedFormButton();
-            await this.clickForm(formName);
-            await this.clickEmbedButton();
+            await this.linkFormToUserTask(formName);
         }
         await this.clickAppendElementButton();
         await this.clickAppendEndEventButton();

package/dist/pages/8.10/ModelerHomePage.d.ts

@@ -56,6 +56,7 @@ declare class ModelerHomePage {
     clickProjectBreadcrumb(): Promise<void>;
     clickWorkspaceBreadcrumb(): Promise<void>;
     enterResourceContainer(name?: string): Promise<void>;
+    private createResourceContainer;
     private clickCreateProcessApplication;
     private ensureInResourceContainer;
     returnToResourceContainer(): Promise<void>;

package/dist/pages/8.10/ModelerHomePage.js

@@ -319,11 +319,33 @@ class ModelerHomePage {
         });
         await this.diagramTypeDropdown.click();
     }
+    // The click landing is not proof the diagram was created: hub creates the
+    // resource and then navigates, so a create that fails server-side leaves the
+    // tab on the container with nothing but a toast. The caller goes straight on
+    // to model, and its wait for the editor can only expire -- reported as
+    // `locator('[data-group-id="group-general"]') ... element(s) not found`,
+    // three reloads later, on a page that was never a diagram. Reloading cannot
+    // conjure one, so confirm the editor URL here and re-issue the create
+    // instead. The caller's own editor wait stays the authority: this returns
+    // after the last attempt rather than throwing, so a genuinely broken create
+    // is still reported by the assertion that needs the editor.
     async clickBpmnTemplateOption() {
-        await (0, test_1.expect)(this.bpmnTemplateOption).toBeVisible({
-            timeout: 15000,
-        });
-        await this.bpmnTemplateOption.click();
+        const maxAttempts = 3;
+        for (let attempt = 1; attempt <= maxAttempts; attempt++) {
+            await (0, test_1.expect)(this.bpmnTemplateOption).toBeVisible({
+                timeout: 15000,
+            });
+            await this.bpmnTemplateOption.click();
+            const opened = await this.page
+                .waitForURL(/\/diagrams\//, { timeout: 60000 })
+                .then(() => true)
+                .catch(() => false);
+            if (opened || attempt === maxAttempts) {
+                return;
+            }
+            console.warn(`No diagram opened on attempt ${attempt}; re-opening the create menu.`);
+            await this.clickDiagramTypeDropdown();
+        }
     }
     async clickFormOption() {
         await this.formTemplateOption.click();
@@ -392,14 +414,60 @@ class ModelerHomePage {
             name ??
                 (await (0, randomName_1.randomNameAgregator)('Cross Component Process Application'));
         console.log(`Creating process application ${this.processApplicationName} inside ${this.defaultFolderName}`);
-        await this.clickCreateProcessApplication();
-        await this.processApplicationPage.nameNewProcessApplication(this.processApplicationName);
+        await this.createResourceContainer(this.processApplicationName);
         this.processApplicationUrl = this.page.url();
         // Remember the container; its stage cluster is bound on the first deploy,
         // by ProcessApplicationPage.ensureStageCluster, which -- unlike this point
         // in the flow -- knows which cluster the test is going to deploy to.
         this.processApplicationPage.rememberResourceContainer(this.processApplicationUrl);
     }
+    // Creates this test's process application, retrying when the creation does
+    // not land.
+    //
+    // A closed creation modal does NOT mean the application exists. Hub's
+    // processApplicationStore.finalizeCreation() catches its own failure: it
+    // toasts "Couldn't create your project. Please try again later." and never
+    // reaches the history.push() into the new application -- but
+    // CreationModal.performRequest() still calls closeModal(), so the submit
+    // looks like it worked while the browser is simply left on the workspace
+    // root. The single wait for the process-application breadcrumb that followed
+    // could then only ever time out
+    // ("breadcrumb-process-application-menu ... element(s) not found"), which was
+    // the largest single source of failures in this spec. The product itself
+    // asks for a retry in that toast, so retry.
+    //
+    // A creation that DID land but rendered slowly must not become a duplicate
+    // container, so every retry first adopts an application already carrying
+    // this name before creating another one.
+    async createResourceContainer(name) {
+        const workspaceUrl = this.page.url();
+        const maxAttempts = 3;
+        for (let attempt = 1; attempt <= maxAttempts; attempt++) {
+            const lastAttempt = attempt === maxAttempts;
+            if (attempt > 1) {
+                await this.page.goto(workspaceUrl, { waitUntil: 'domcontentloaded' });
+                if (await this.processApplicationPage.openByNameIfPresent(name)) {
+                    return;
+                }
+                // The adopt probe may have clicked into an application that then
+                // failed to render, so come back to the workspace root: the create
+                // controls this attempt needs only exist there.
+                await this.page.goto(workspaceUrl, { waitUntil: 'domcontentloaded' });
+            }
+            try {
+                await this.clickCreateProcessApplication();
+                await this.processApplicationPage.nameNewProcessApplication(name, lastAttempt ? 90000 : 45000);
+                return;
+            }
+            catch (error) {
+                if (lastAttempt) {
+                    throw error;
+                }
+                console.warn(`Process application "${name}" did not open ` +
+                    `on attempt ${attempt}/${maxAttempts}; retrying the creation.`);
+            }
+        }
+    }
     // Which control creates a process application depends on the hub version
     // under test. Since camunda/camunda-hub#25831 it is a plain primary button on
     // the workspace root, and the "Create new" menu explicitly hides the item
@@ -412,6 +480,15 @@ class ModelerHomePage {
         const rootLoaded = await this.becameVisible(button.or(this.diagramTypeDropdown).first(), 60000);
         if (!rootLoaded) {
             await this.page.reload();
+            await this.page.waitForLoadState('domcontentloaded');
+            // Re-run the joint probe after the reload. The short confirmation below
+            // assumes the workspace root has already rendered one of the two entry
+            // points, which straight after a reload it has not: probing the button
+            // alone for 5s there reported "absent" on a root that was merely still
+            // loading, sent the flow down the create-menu branch, and waited out its
+            // full 60s on a `[data-test="diagram-dropdown"]` that the empty-state
+            // root never renders.
+            await this.becameVisible(button.or(this.diagramTypeDropdown).first(), 60000);
         }
         // Short: the joint probe above already settled which branch rendered, and
         // hub renders exactly one of them (EntityTable renders the toolbar's create
@@ -445,6 +522,16 @@ class ModelerHomePage {
         await this.page.goto(this.processApplicationUrl, {
             waitUntil: 'domcontentloaded',
         });
+        // One reload before spending the whole budget: processApplicationStore
+        // .init() swallows a failed fetch (it only toasts "Yikes! Couldn't
+        // retrieve your project" and clears its loading flag), so a transient 5xx
+        // leaves a fully rendered page that simply has no process-application
+        // breadcrumb -- waiting the full 90s on it can only ever time out, and
+        // re-running the store init is the only thing that brings it back.
+        const backInside = await this.becameVisible(this.processApplicationPage.breadcrumb, 45000);
+        if (!backInside) {
+            await this.page.reload({ waitUntil: 'domcontentloaded' });
+        }
         await this.processApplicationPage.waitForProcessApplication();
         await this.dismissBlockingDialog();
     }
@@ -499,8 +586,13 @@ class ModelerHomePage {
             visibilityTimeout: 60000,
             // Widened from 180s: dismissing the announcement dialog costs up to ~25s
             // of settle-and-probe per attempt, which at 180s left room for barely one
-            // retry after an intercepted click had already burnt its 60s.
-            totalTimeout: 240000,
+            // retry after an intercepted click had already burnt its 60s. 240s was
+            // still short of what maxRetries asks for -- preAction (~40s) plus the
+            // 60s visibility budget makes an attempt cost ~100s, so the helper gave
+            // up "after 3 attempts" with two retries left unused. Budget for the
+            // retries it is configured for, while still leaving room inside the test
+            // timeout for the helper's own error to be the one reported.
+            totalTimeout: 540000,
             maxRetries: 5,
             preAction: async () => {
                 // Dismiss the dialog BEFORE the banner: the Modeler home page can

package/dist/pages/8.10/ProcessApplicationPage.d.ts

@@ -19,12 +19,13 @@ declare class ProcessApplicationPage {
     waitForProcessApplication(timeout?: number): Promise<void>;
     clickCreateProcessApplicationButton(): Promise<void>;
     clickCreateProcessApplicationOption(): Promise<void>;
-    nameNewProcessApplication(name: string): Promise<void>;
+    nameNewProcessApplication(name: string, readyTimeout?: number): Promise<void>;
     defineDevelopmentStage(clusterName?: string): Promise<void>;
     rememberResourceContainer(url: string): void;
     forgetStageCluster(): void;
     ensureStageCluster(clusterName: string): Promise<boolean>;
     private openStageDefinition;
+    openByNameIfPresent(name: string, timeout?: number): Promise<boolean>;
     openByName(name: string): Promise<void>;
 }
 export { ProcessApplicationPage };

package/dist/pages/8.10/ProcessApplicationPage.js

@@ -117,7 +117,14 @@ class ProcessApplicationPage {
     // editable title before, and #27593 is still moving this surface, so the
     // inline path is kept as a fallback — this is the one method that has to
     // change if naming moves back inline.
-    async nameNewProcessApplication(name) {
+    //
+    // readyTimeout is how long the caller is prepared to wait for the created
+    // application to actually open. It is a parameter because a closed modal
+    // does NOT mean the application exists (see
+    // ModelerHomePage.createResourceContainer): a caller that can retry the
+    // whole creation wants to find that out quickly rather than spend the full
+    // budget on a page that is never going to render.
+    async nameNewProcessApplication(name, readyTimeout = 90000) {
         const isModal = await this.creationDialog
             .waitFor({ state: 'visible', timeout: 15000 })
             .then(() => true)
@@ -127,14 +134,14 @@ class ProcessApplicationPage {
             await this.nameInput.fill(name);
             await (0, test_1.expect)(this.nameInput).toHaveValue(name, { timeout: 10000 });
             await (0, submitModalWithRetry_1.submitModalWithRetry)(this.submitButton, this.creationDialog);
-            await this.waitForProcessApplication();
+            await this.waitForProcessApplication(readyTimeout);
             return;
         }
         await (0, test_1.expect)(this.inlineNameInput).toBeVisible({ timeout: 30000 });
         await this.inlineNameInput.click({ timeout: 60000 });
         await this.inlineNameInput.fill(name);
         await this.inlineNameInput.press('Enter');
-        await this.waitForProcessApplication();
+        await this.waitForProcessApplication(readyTimeout);
     }
     // Assigns a cluster to this process application's development stage.
     //
@@ -190,8 +197,17 @@ class ProcessApplicationPage {
             await option.click({ timeout: 15000, force: true });
             await (0, test_1.expect)(option).toBeHidden({ timeout: 15000 });
         }).toPass({ timeout: 120000, intervals: [1000, 2000, 5000] });
-        await this.defineStagesSaveButton.click({ timeout: 30000 });
-        await (0, test_1.expect)(this.defineStagesDialog).toBeHidden({ timeout: 60000 });
+        // Saving is retried the same way the option click is, and for the same
+        // reason: the click resolving is not proof the save was taken. The nightly
+        // recorded a Save that reported success and left the dialog standing --
+        // `expect(getByRole('dialog').filter({hasText: 'Define stages'}))
+        // .toBeHidden()` re-resolving it 63 times over 60s -- which one long wait
+        // can only sit out. A save that did land closes the dialog, so the dialog
+        // still being there is itself the signal to press Save again.
+        await (0, test_1.expect)(async () => {
+            await this.defineStagesSaveButton.click({ timeout: 15000 });
+            await (0, test_1.expect)(this.defineStagesDialog).toBeHidden({ timeout: 20000 });
+        }).toPass({ timeout: 120000, intervals: [1000, 2000, 5000] });
     }
     rememberResourceContainer(url) {
         resourceContainers.set(this.page, { url });
@@ -289,6 +305,29 @@ class ProcessApplicationPage {
             await (0, test_1.expect)(this.defineStagesDialog).toBeVisible({ timeout: 15000 });
         }).toPass({ timeout: 180000 });
     }
+    // Adopts an application that already carries this name on the workspace
+    // root, reporting whether it opened. Used by the creation retry so a
+    // creation that did land but rendered slowly is re-entered instead of being
+    // duplicated by the next attempt.
+    async openByNameIfPresent(name, timeout = 15000) {
+        const processApplication = this.page
+            .getByRole('row')
+            .filter({ hasText: name })
+            .getByTitle(name)
+            .first();
+        const present = await processApplication
+            .waitFor({ state: 'visible', timeout })
+            .then(() => true)
+            .catch(() => false);
+        if (!present) {
+            return false;
+        }
+        await processApplication.click({ timeout: 60000 });
+        return await this.pageReady()
+            .waitFor({ state: 'visible', timeout: 60000 })
+            .then(() => true)
+            .catch(() => false);
+    }
     async openByName(name) {
         const processApplication = this.page
             .getByRole('row')

package/dist/pages/8.10/UtilitiesPage.js

@@ -102,6 +102,35 @@ async function waitForLoginForm(page, loginPage, totalTimeout = 90000, roundTime
 // rather than on every call -- see the comment at the call site.
 const staggeredWorkerTimeouts = new Set();
 async function loginWithRetry(page, loginPage, testUser, timeout, maxRetries = 5) {
+    // A blank credential is not something retrying can fix, and from inside the
+    // browser it does not look like a credential problem at all: the form takes
+    // the empty password, auth0 keeps the tab on its own page, and the failure
+    // surfaces a minute later as the Console banner "element(s) not found" --
+    // five times over, plus the test-level retry.
+    //
+    // Run 35320545635 spent 22 minutes that way on one empty password, and since
+    // the caller is test-setup.spec.ts the 239 tests depending on that setup
+    // project never ran. The password was empty because GitHub refused to set
+    // the job output carrying it ("Skip output 'c8_org_1_admin_9_password' since
+    // it may contain secret" in the create-organization job): a job output whose
+    // value contains a masked secret is dropped, and a freshly generated Console
+    // password can contain one by chance -- this repo already has a masked value
+    // two characters long, see the counting trap in
+    // docs/saas-login-investigation.md. Which password it hits is luck, so the
+    // job cannot be trusted to have delivered them all. Say so here, in one
+    // second, instead of spending the suite's budget proving it through the UI.
+    if (!testUser?.username || !testUser?.password) {
+        const missing = [
+            testUser?.username ? null : 'username',
+            testUser?.password ? null : 'password',
+        ]
+            .filter(Boolean)
+            .join(' and ');
+        throw new Error(`Cannot log in: this test user has no ${missing}. The credential never ` +
+            'reached the runner -- check the create-organization job for a ' +
+            '"Skip output ... since it may contain secret" warning on the ' +
+            'matching C8_*_PASSWORD output.');
+    }
     let lastError;
     // `timeout` is a stable per-worker identifier (derived from workerIndex),
     // and a worker is a long-lived process across every test/repeat it runs, so

package/dist/tests/8.10/web-modeler-user-flows.spec.js

@@ -58,11 +58,14 @@ _8_10_1.test.describe('Web Modeler User Flow Tests', () => {
             await (0, test_1.expect)(homePage.camundaComponentsButton).toBeVisible({
                 timeout: 120000,
             });
-            await appsPage.clickCamundaApps();
-            await appsPage.clickModeler();
-            await (0, test_1.expect)(modelerHomePage.modelerPageBanner).toBeVisible({
-                timeout: 180000,
-            });
+            // Gate on the projects list, not on the Modeler banner alone: Modeler
+            // renders that banner on its own login page too, so a hand-off whose
+            // `POST /api/internal/login` 500s -- which makes hub log the user
+            // straight back out -- passed this step and failed two steps later as an
+            // unclickable project tile. openModelerWithRetry re-runs the handshake,
+            // and with it the internal login, when Modeler is not actually signed
+            // in.
+            await appsPage.openModelerWithRetry(modelerHomePage.modelerPageBanner, 90000, 3, modelerHomePage.createNewProjectButton);
         });
         await _8_10_1.test.step('Open Cross Component Test Project', async () => {
             await modelerHomePage.clickCrossComponentProjectFolder();

package/dist/utils/apiHelpers.js

@@ -772,6 +772,16 @@ async function performOptimizeInteractiveLogin(page, callerLabel, verifySession)
             if (loginAttempt < maxLoginAttempts - 1) {
                 const rateLimited = String(error).includes(utils_1.AUTH0_RATE_LIMIT);
                 const unauthenticated = String(error).includes(OPTIMIZE_SESSION_UNAUTHENTICATED);
+                // loginToApp rethrows a bare Playwright TimeoutError when its own
+                // page.waitForURL never sees the post-login redirect land (run
+                // 35340608406, optimize-collections-api.spec.ts "Delete non-existent
+                // collection"). That is the same sso-callback rejection burst the
+                // "unauthenticated" branch below backs off for -- Auth0 answered the
+                // login but the redirect back to Optimize never completed -- so it
+                // needs the same growing backoff, not the flat 10-20s fallback below
+                // meant for genuinely unclassified errors. Without this, that attempt
+                // just retried straight back into the same burst.
+                const navigationTimeout = String(error).includes('waitForURL');
                 console.warn(`${callerLabel}: login attempt ${loginAttempt + 1} failed, retrying after backoff...`, error);
                 await page.goto('about:blank');
                 if (rateLimited) {
@@ -780,7 +790,7 @@ async function performOptimizeInteractiveLogin(page, callerLabel, verifySession)
                     // the same window and burns the attempt budget for nothing.
                     await (0, randomSleep_1.randomSleep)(60000, 90000);
                 }
-                else if (unauthenticated) {
+                else if (unauthenticated || navigationTimeout) {
                     // The rejected callbacks come in bursts lasting tens of seconds
                     // (every login inside the burst window fails, isolated ones all
                     // succeed), so back off past the burst rather than retrying inside
@@ -789,8 +799,9 @@ async function performOptimizeInteractiveLogin(page, callerLabel, verifySession)
                     // the same distribution at the same moment, so a fixed band keeps
                     // the herd synchronised and they re-collide on the next attempt.
                     // Growing the ceiling fans them out while the floor still lets a
-                    // lucky worker recover quickly. Worst case stays well inside the
-                    // 12-minute hook timeout.
+                    // lucky worker recover quickly. Worst case (3 retries at the
+                    // ceiling, plus the initial stagger) stays under 6 minutes, well
+                    // inside the 12-minute test timeout.
                     await (0, randomSleep_1.randomSleep)(20000, 45000 + loginAttempt * 45000);
                 }
                 else {

package/dist/utils/assertionHelpers/submitModalWithRetry.d.ts

@@ -2,4 +2,5 @@ import { Locator } from '@playwright/test';
 export declare const submitModalWithRetry: (submitButton: Locator, modal: Locator, options?: {
     maxRetries?: number;
     closeTimeout?: number;
+    settleTimeout?: number;
 }) => Promise<void>;

package/dist/utils/assertionHelpers/submitModalWithRetry.js

@@ -9,9 +9,29 @@ const test_1 = require("@playwright/test");
 // the form fields remain valid, so re-submitting recovers from the transient
 // blip. A persistent failure exhausts the retries and is surfaced to the caller.
 const submitModalWithRetry = async (submitButton, modal, options) => {
-    const { maxRetries = 3, closeTimeout = 20000 } = options || {};
+    const { maxRetries = 3, closeTimeout = 20000, settleTimeout = 30000, } = options || {};
     let lastError;
     for (let attempt = 1; attempt <= maxRetries; attempt++) {
+        // A submit that is still in flight keeps the primary button disabled --
+        // hub's process-application creation modal renders
+        // `primaryButtonDisabled={!hasValidName || isSubmitting}` -- so a blind
+        // retry click waits out its whole action timeout on a button that was
+        // never going to accept it ("locator resolved to <button disabled ...>,
+        // element is not enabled"). Let the previous submit settle first: either
+        // it lands and closes the modal, or the button comes back enabled and the
+        // retry is a real retry.
+        if (attempt > 1) {
+            let enabled = true;
+            try {
+                await (0, test_1.expect)(submitButton).toBeEnabled({ timeout: settleTimeout });
+            }
+            catch {
+                enabled = false;
+            }
+            if (!enabled && !(await modal.isVisible())) {
+                return;
+            }
+        }
         await submitButton.click();
         try {
             await (0, test_1.expect)(modal).not.toBeVisible({ timeout: closeTimeout });

package/package.json

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