Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Happy path E2E tests failed on 'Run debug and check application stop in the breakpoint' step #18034

Closed
5 of 22 tasks
dmytro-ndp opened this issue Oct 2, 2020 · 30 comments
Closed
5 of 22 tasks
Assignees
Labels
e2e-test/failure Issues that is related to a test failures reported by our CI platform and our QE. kind/bug Outline of a bug - must adhere to the bug report template. severity/P1 Has a major impact to usage or development of the system.

Comments

@dmytro-ndp
Copy link
Contributor

dmytro-ndp commented Oct 2, 2020

Describe the bug

Happy path E2E tests failed on 'Run debug and check application stop in the breakpoint' step on minikube and minishift from time to time:
https://ci.centos.org/view/Devtools/job/devtools-che-nightly-happy-path-test/237/console
https://codeready-workspaces-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/basic-MultiUser-Che-check-e2e-tests-against-k8s/2318/consoleFull

          ▼ Editor.selectTab "WelcomeController.java"
          ▼ Editor.waitTab "WelcomeController.java"
          ▼ Editor.clickOnTab "WelcomeController.java"
          ▼ Editor.waitTabFocused "WelcomeController.java"
          ▼ TopMenu.selectOption "View"
          ▼ TopMenu.clickOnTopMenuButton "View"
          ▼ Ide.closeAllNotifications
          ▼ NotificationCenter.open
          ▼ NotificationCenter.clickIconOnStatusBar
          ▼ NotificationCenter.waitOpening
          ▼ NotificationCenter.closeAll
          ▼ NotificationCenter.clickCloseAllNotificationsButton
          ▼ NotificationCenter.waitClearNotificationsList
          ▼ TopMenu.clickOnSubmenuItem "Debug"
          ▼ Ide.waitLeftToolbarButton
          ▼ DebugView.clickOnDebugConfigurationDropDown
          ▼ DebugView.clickOnDebugConfigurationItem "Debug (Attach) - Remote"
          ▼ Ide.performKeyCombination ""
          ▼ DebugView.clickOnRunDebugButton
          ▼ Waiting for debugger to connect (threads to appear in "Threads" view)
...
          ▼ Waiting for debugger to connect (threads to appear in "Threads" view)
    1) Run debug and check application stop in the breakpoint


  21 passing (11m)
  1 pending
  1 failing

  1) Validation of debug functionality
       Run debug and check application stop in the breakpoint:
     TimeoutError: Wait timed out after 30001ms
      at /tmp/e2e/node_modules/selenium-webdriver/lib/promise.js:2201:17
      at ManagedPromise.invokeCallback_ (/tmp/e2e/node_modules/selenium-webdriver/lib/promise.js:1376:14)
      at TaskQueue.execute_ (/tmp/e2e/node_modules/selenium-webdriver/lib/promise.js:3084:14)
      at TaskQueue.executeNext_ (/tmp/e2e/node_modules/selenium-webdriver/lib/promise.js:3067:27)
      at asyncRun (/tmp/e2e/node_modules/selenium-webdriver/lib/promise.js:2927:27)
      at /tmp/e2e/node_modules/selenium-webdriver/lib/promise.js:668:7
      at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:188:7)
  From: Task: <anonymous wait>
      at scheduleWait (/tmp/e2e/node_modules/selenium-webdriver/lib/promise.js:2188:20)
      at ControlFlow.wait (/tmp/e2e/node_modules/selenium-webdriver/lib/promise.js:2517:12)
      at thenableWebDriverProxy.wait (/tmp/e2e/node_modules/selenium-webdriver/lib/webdriver.js:934:29)
      at DebugView.waitForDebuggerToConnect (/tmp/e2e/pageobjects/ide/DebugView.ts:53:45)
      at Context.test (/tmp/e2e/tests/e2e_happy_path/HappyPath.spec.ts:259:25)
      at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:188:7)

Che version

  • latest
  • nightly
  • other: please specify

Steps to reproduce

Happy path tests script

Expected behavior

Runtime

  • kubernetes (include output of kubectl version)
  • Openshift (include output of oc version)
  • minikube 1.1.1 (include output of minikube version and kubectl version)
  • minishift 3.11 (include output of minishift version and oc version)
  • docker-desktop + K8S (include output of docker version and kubectl version)
  • other: (please specify)

Screenshots

screenshot-Run_debug_and_check_application_stop_in_the_breakpoint

Screencast

https://youtu.be/jqfECJXL5EQ

Installation method

  • chectl
    • provide a full command that was used to deploy Eclipse Che (including the output)
    • provide an output of chectl version command
  • OperatorHub
  • I don't know

Environment

  • my computer
    • Windows
    • Linux
    • macOS
  • Cloud
    • Amazon
    • Azure
    • GCE
    • other (please specify)
  • other: CRW CCI, Centos CI

Eclipse Che Logs

Additional context

@dmytro-ndp dmytro-ndp added kind/bug Outline of a bug - must adhere to the bug report template. e2e-test/failure Issues that is related to a test failures reported by our CI platform and our QE. team/che-qe area/qe labels Oct 2, 2020
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Oct 2, 2020
@sleshchenko sleshchenko added severity/blocker Causes system to crash and be non-recoverable or prevents Che developers from working on Che code. and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Oct 5, 2020
@sleshchenko
Copy link
Member

Assigning severity/blocker since AFAIU it prevents new PRs from being merged.

@tsmaeder
Copy link
Contributor

tsmaeder commented Oct 5, 2020

@dmytro-ndp youtube says "this video is private".

@dmytro-ndp
Copy link
Contributor Author

dmytro-ndp commented Oct 5, 2020

@tsmaeder: sorry for that.
Screencast should be public now https://youtu.be/jqfECJXL5EQ

@tsmaeder
Copy link
Contributor

tsmaeder commented Oct 5, 2020

@dmytro-ndp the sequence of events in the video seems to be:

  1. Set a break point
  2. Start the application
  3. Open the preview
  4. Connect the debugger
  5. Nothing

I don't see a refresh in the browser: why would you expect the breakpoint to be hit if the code is not executed again?

@rhopp rhopp added this to the Backlog - QE milestone Oct 7, 2020
@rhopp rhopp added severity/P1 Has a major impact to usage or development of the system. and removed severity/P1 Has a major impact to usage or development of the system. labels Oct 7, 2020
@dmytro-ndp
Copy link
Contributor Author

dmytro-ndp commented Oct 8, 2020

@tsmaeder: thank you for investigation!
If you look at normal debug flow https://www.youtube.com/watch?v=dN1oprNuyyg&feature=youtu.be&t=600, you might notice that there should threads in THREADS list be appeared after connection to debugger:

Expected THREADS list

Screenshot from 2020-10-08 19-13-35

Actual THREADS list

94930321-e794e100-04ce-11eb-8e47-c43250657203

@dmytro-ndp dmytro-ndp added severity/P1 Has a major impact to usage or development of the system. and removed severity/blocker Causes system to crash and be non-recoverable or prevents Che developers from working on Che code. labels Oct 8, 2020
@dmytro-ndp
Copy link
Contributor Author

dmytro-ndp commented Oct 8, 2020

Changed priority, because the issue hasn't been reproduced during the last few days.

@rhopp
Copy link
Contributor

rhopp commented Oct 8, 2020

@dmytro-ndp The crucial difference between "normal" flow and this bug is that in the "normal" flow, the preview widget gets reloaded (which triggers the breakpoint). That's what's missing in the screencast of this bug, as Thomas was saying.

@dmytro-ndp
Copy link
Contributor Author

@rhopp: that is not true. If you look at normal flow screen cast, you will see that threads had appeared in the THREADS list BEFORE the test was refreshed preview tabs.

@rhopp
Copy link
Contributor

rhopp commented Oct 8, 2020

TBH... I blame that on slow UI.
I don't see how the breakpoint could have been triggered, when the code was not being executed (the code gets executed, when the page is loading...)

@rhopp
Copy link
Contributor

rhopp commented Oct 8, 2020

Ok. Dmytro proved me wrong... I was thinking (the same way as Thomas), that the test failed on waiting for the breakpoint to be hit, but that's not the case.
After executing "Debug (Attach)" in debug view, the test is waiting for active threads to be shown in the left panel in "Threads" section (here and that's what fails, because on the failed cases, all the sections in the debug panel are collapsed.

@vzhukovs
Copy link
Contributor

vzhukovs commented Feb 10, 2021

@dmytro-ndp, Vanilla Theia has the same behavior: #18564 (comment), so, what can I propose is to not stick to the specific items in a list, but check, for example whether the view is collapsed or not. If collapsed, then expand. Or choose another DOM elements that can be an anchor for testing scenario. If you switch to the debugger panel and refresh the page, the application state will be restored in the same way as it was before reloading. cc @azatsarynnyy

@azatsarynnyy
Copy link
Member

Thanks @vzhukovs for checking it.
I'm removing che-theia label as, Che-Theia state restoring has been already improved by eclipse-che/che-theia#970

@azatsarynnyy azatsarynnyy removed the area/editor/theia Issues related to the che-theia IDE of Che label Feb 10, 2021
@dmytro-ndp dmytro-ndp self-assigned this Feb 11, 2021
@dmytro-ndp dmytro-ndp added team/che-qe severity/blocker Causes system to crash and be non-recoverable or prevents Che developers from working on Che code. status/in-progress This issue has been taken by an engineer and is under active development. and removed severity/P1 Has a major impact to usage or development of the system. labels Feb 11, 2021
@dmytro-ndp dmytro-ndp removed the status/in-progress This issue has been taken by an engineer and is under active development. label Feb 12, 2021
@benoitf
Copy link
Contributor

benoitf commented Feb 12, 2021

@benoitf benoitf reopened this Feb 12, 2021
@dmytro-ndp
Copy link
Contributor Author

dmytro-ndp commented Mar 13, 2021

@benoitf: thank you update!
I haven't seen the issue in PR check on CRW CCI since resolution.
Could you, please, confirm that the issue is still reproducing in newer Che versions?
If yes, there is too little information in test logs to understand what exactly was going wrong at the moment, and it's hard to find a root cause of issue without screenshot/screencast. Setting TRACE log level should bring more information:

-e TS_SELENIUM_LOG_LEVEL="TRACE"

Please, review corresponding PR to Happy path tests che-incubator/happy-path-tests-action#1

@nickboldt
Copy link
Contributor

As this has now had 3 milestone designations (7.26, 7.27, 7.28) I've moved it to 7.x as it's either not getting done, or needs an owner to set a valid fixversion.

@dmytro-ndp dmytro-ndp added severity/P1 Has a major impact to usage or development of the system. and removed severity/blocker Causes system to crash and be non-recoverable or prevents Che developers from working on Che code. labels Jun 14, 2021
@dmytro-ndp dmytro-ndp added sprint/current status/in-progress This issue has been taken by an engineer and is under active development. and removed sprint/current status/in-progress This issue has been taken by an engineer and is under active development. labels Jul 1, 2021
@dmytro-ndp
Copy link
Contributor Author

Closing the issue because the problem hasn't been reproduced for a long time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
e2e-test/failure Issues that is related to a test failures reported by our CI platform and our QE. kind/bug Outline of a bug - must adhere to the bug report template. severity/P1 Has a major impact to usage or development of the system.
Projects
None yet
Development

No branches or pull requests