Skip to content

Plugin "retryFailedStep" doesn't work in --debug or --verbose mode, searching for element fails immediately #4384

Description

@mirao

It's a regression in 3.6.0.
It works well with 3.5.15.

What are you trying to achieve?

You should see the Retrying... Attempt ... retries in the following test.

This is how it works with 3.5.15 ✔️

CodeceptJS v3.5.15 #StandWithUkraine
Using test root "/home/mirao/workspace/codeceptjs/tests/my"
Helpers: Playwright
Plugins: screenshotOnFail, retryFailedStep

My --
    [1]  Starting recording promises
    Timeouts: 
 › [Session] Starting singleton browser session
  test something
    I see element ".blabla"
    [1] Retrying... Attempt #2
    [1] Retrying... Attempt #3
    [1] Retrying... Attempt #4
    [1] Error (Non-Terminated) | Error: Element ".blabla" is not visible on page. | (err) => { step.status = 'failed'; step.endTime = ...
    [1] Error | Error: Element ".blabla" is not visible on page. undefined...
    [1] <teardown> Stopping recording promises
 › <screenshotOnFail> Test failed, try to save a screenshot
 › Screenshot is saving to /home/mirao/workspace/codeceptjs/tests/my/output/test_something.failed.png
  ✖ FAILED in 1148ms

    [2]  Starting recording promises

-- FAILURES:

  1) My
       test something:
     Element ".blabla" is not visible on page.
      at dontSeeElementError (/home/mirao/workspace/codeceptjs/node_modules/.pnpm/codeceptjs@3.5.15_@babel+core@7.24.7_@babel+preset-env@7.24.7_react@18.2.0_typescript@4.8.2/node_modules/codeceptjs/lib/helper/errors/ElementAssertion.js:23:9)
      at Playwright.seeElement (/home/mirao/workspace/codeceptjs/node_modules/.pnpm/codeceptjs@3.5.15_@babel+core@7.24.7_@babel+preset-env@7.24.7_react@18.2.0_typescript@4.8.2/node_modules/codeceptjs/lib/helper/Playwright.js:1460:7)
  
  Scenario Steps:
  - I.seeElement(".blabla") at Test.<anonymous> (./My_test.ts:4:7)
  
  Artifacts:
  - screenshot: /home/mirao/workspace/codeceptjs/tests/my/output/test_something.failed.png


  FAIL  | 0 passed, 1 failed   // 2s

What do you get instead?

Provide console output if related. Use --verbose mode for more details.

This is how it works with 3.6.0 or 3.6.2 🐛

CodeceptJS v3.6.0 #StandWithUkraine
Using test root "/home/mirao/workspace/codeceptjs/tests/my"
Helpers: Playwright
Plugins: screenshotOnFail, retryFailedStep

My --
    [1]  Starting recording promises
    Timeouts: 
 › [Session] Starting singleton browser session
  test something
    I see element ".blabla"
    [1]  Error (Non-Terminated) | Error: Element ".blabla" is not visible on page. | (err) => { step.status = 'failed'; step.endTime = ...
    [1] Error | Error: Element ".blabla" is not visible on page. undefined...
    [1] <teardown>  Stopping recording promises
 › <screenshotOnFail> Test failed, try to save a screenshot
 › Screenshot is saving to /home/mirao/workspace/codeceptjs/tests/my/output/test_something.failed.png
  ✖ FAILED in 117ms

    [2]  Starting recording promises

-- FAILURES:

  1) My
       test something:
     Element ".blabla" is not visible on page.
      at dontSeeElementError (/home/mirao/workspace/codeceptjs/node_modules/.pnpm/codeceptjs@3.6.0_@babel+core@7.24.7_@babel+preset-env@7.24.7_react@18.2.0_typescript@4.8.2/node_modules/codeceptjs/lib/helper/errors/ElementAssertion.js:23:9)
      at Playwright.seeElement (/home/mirao/workspace/codeceptjs/node_modules/.pnpm/codeceptjs@3.6.0_@babel+core@7.24.7_@babel+preset-env@7.24.7_react@18.2.0_typescript@4.8.2/node_modules/codeceptjs/lib/helper/Playwright.js:1464:7)
  
  Scenario Steps:
  - I.seeElement(".blabla") at Test.<anonymous> (./My_test.ts:4:7)
  
  Artifacts:
  - screenshot: /home/mirao/workspace/codeceptjs/tests/my/output/test_something.failed.png


  FAIL  | 0 passed, 1 failed   // 574ms

Provide test source code if related

Feature("My");

Scenario("test something", ({ I }) => {
    I.seeElement(".blabla");
});

Details

  • CodeceptJS version: 3.6.0 or 3.6.2
  • NodeJS Version: 18.20
  • Operating System: Ubuntu 22.04
  • Playwright Version 1.43.1
  • Configuration file:
export const config: CodeceptJS.MainConfig = {
    tests: "./*_test.ts",
    output: "./output",
    helpers: {
        Playwright: {
            browser: "chromium",
            url: "http://localhost",
            show: true,
        },
    },
    plugins: {
        retryFailedStep: {
            enabled: true,
        },
    },
    name: "my",
};

Activity

  1. mirao commented on Jun 14, 2024

    @mirao
    ContributorAuthor

    Interestingly it works well in a "shell" mode (tested with 3.6.3):

    $ codeceptjs shell --verbose
    Interactive shell started
     Use JavaScript syntax to try steps in action
     - Press ENTER to run the next step
     - Press TAB twice to see all available commands
     - Type exit + Enter to exit the interactive shell
     - Prefix => to run js commands 
     I.seeElement(".blabla")
        [1] <pause> Retrying... Attempt #2
        [1] <pause> Retrying... Attempt #3
    
  2. mirao commented on Jun 14, 2024

    @mirao
    ContributorAuthor

    Well, only --debug or --verbose mode is affected.
    And if I comment out this line:

    if (options.verbose || options.debug) store.debugMode = true;

    everything works well even in --verbose mode.

    store.debugMode seems to be needed for healers only? #4230

    @DavertMik

  3. changed the title [-]Plugin "retryFailedStep" doesn't work, searching for element fails immediately[/-] [+]Plugin "retryFailedStep" doesn't work in --debug or --verbose mode, searching for element fails immediately[/+] on Jun 14, 2024
  4. DavertMik commented on Jun 16, 2024

    @DavertMik
    Contributor

    Thanks, I'm checking

  5. mirao commented on Jun 20, 2024

    @mirao
    ContributorAuthor

    I "solved" it a different way to myself.
    I patched the retryFailedStep plugin - I removed this line

    if (store.debugMode) return false;

    It seems to me that the removing doesn't affect functionality of the plugin. I tested the plugin in non-verbose mode, --verbose mode, in shell mode and for pause()

  6. github-actions commented on Sep 19, 2024

    @github-actions

    This issue is stale because it has been open for 90 days with no activity.

  7. javierfuentesm commented on Mar 5, 2025

    @javierfuentesm

    Are there any updates? @DavertMik 🫣 im facing the same issue

  8. emiliangrecu commented on Mar 6, 2025

    @emiliangrecu

    I am also facing this problem.

  9. added a commit that references this issue on Sep 2, 2025
    f5cc169
  10. added a commit that references this issue on Sep 11, 2026
    c156f79
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions