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

Stack trace log (failed line number) printed in cypress run is different from the stack trace in cypress open #7715

Closed
frankliu1776 opened this issue Jun 16, 2020 · 14 comments · Fixed by #23575
Assignees
Labels

Comments

@frankliu1776
Copy link

frankliu1776 commented Jun 16, 2020

Current behavior:

  1. when run a cypress script on terminal with command: ./node_modules/.bin/cypress run --port 3019 --browser chrome --config testFiles=myCypressPath/cypress/test/20200426172648.js
    I can get stack trace printed in terminal like:
    image
    We can see that the log indicates the failed line number is in line 24, which is not correct
  2. in the meanwhile when I run it with cypress open, it indicates that the failed line number is 31 which is correct:
    image

Desired behavior:

how can I get correct stack trace on ternimal? I am using some automation framework to automate cypress scripts and parse the stack trace log to get failed line number

Test code to reproduce

var test1 = "http://argo-ui.oss-cn-beijing.aliyuncs.com/test.js";
var test2 = "http://argo-ui.oss-cn-beijing.aliyuncs.com/test (2).js";
var test4 = 111111;
describe('test_name', function() {

 it('what_it_does', function() {

    cy.viewport(1024, 768)

    cy.setCookie('currentRegionId', 'test')
    cy.wait(4000)
 
    cy.visit('https://test.com')
cy.clickText('尊敬的用户');
cy.wait(3000)
    cy.wait(1000)
    cy.visit('https://test.com')

    cy.wait(1000)
 
    cy.get('li.J_submenu_edasAppManage > div.el-submenu__title > div:nth-child(1) > div').click()
 
    cy.wait(2000)
 
    cy.xpath('//div[text()="配置管理"]').click()
 
    cy.wait(4000)
    cy.visit('https://test.com/?regionNo=test')
    
    cy.wait(2000)
    cy.getIFrameBody('.J_iframe_Contianer').xpath('//span[text()="创建"]').click()
 
    cy.wait(2000)
 
    cy.getIFrameBody('.J_iframe_Contianer').find('#dataId').click()
 
    cy.wait(1000)
 
    cy.getIFrameBody('.J_iframe_Contianer').find('#dataId').clear().type('dfdfdfdfdfdfiiii')
 
    cy.wait(1000)
 
    cy.getIFrameBody('.J_iframe_Contianer').find('div.view-lines').click()
 
    cy.wait(2000)
 
    cy.getIFrameBody('.J_iframe_Contianer').find('textarea.inputarea').clear().type('fdfdfdfdf')
 
    cy.wait(1000)
 
    cy.getIFrameBody('.J_iframe_Contianer').find('button.next-btn-primary').click()
 
    cy.wait(1000)
 
    cy.getIFrameBody('.J_iframe_Contianer').find('div.next-dialog-footer > div > button[type="button"].next-btn-medium').click()
 
    cy.wait(1000)
 
    cy.getIFrameBody('.J_iframe_Contianer').find('button.next-btn-normal').click()

 })
})

Versions

Cypress: 4.7.0
operating system: MacOS Catalina 10.15.5
browser: chrome 83.0.4103.97

@frankliu1776
Copy link
Author

frankliu1776 commented Jun 16, 2020

it is a simple case, if your charset doesn't support Chinese please modify them to English, thanks.

@jennifer-shehane
Copy link
Member

Yes, I think this may be due to the something with the code/filename being in Chinese unicode characters. We had a previous issue with the values dispalying incorrectly in the code frame that looks similar: #7507

@frankliu1776 Can you provide test code that we can run completely to see the error ourselves? I can't run the current code without the url to visit, the clickText and getIFrameBody methods provided. Thanks.

@jennifer-shehane
Copy link
Member

jennifer-shehane commented Jun 16, 2020

Actually I found a way to recreate this. The problems in this issue are twofold:

  1. The line/column number of stack traces differs between cypress run and cypress open. This happens regardless of unicode characters being present.

    spec.js

    it('fails', () => {
      cy.get('foo')
    })

    cypress open is correct line/column number 2:6

    Screen Shot 2020-06-16 at 1 45 24 PM

    cypress run is incorrect line/column number 5:6

    Screen Shot 2020-06-16 at 1 46 42 PM
  2. When a path contains unicode characters, they are not properly shown in the link to the stack trace file in the Command Log. This should be easily fixable.

    cypress/integration/配置管理.js

    it('fails', () => {
      cy.get('foo')
    })
    Screen Shot 2020-06-16 at 1 43 37 PM

Screen Shot 2020-06-16 at 1 54 48 PM

@jennifer-shehane jennifer-shehane added topic: code frame v4.6.0 🐛 Issue present since 4.6.0 labels Jun 16, 2020
@cypress-bot cypress-bot bot added the stage: ready for work The issue is reproducible and in scope label Jun 16, 2020
@jennifer-shehane jennifer-shehane added type: bug and removed stage: ready for work The issue is reproducible and in scope labels Jun 16, 2020
@frankliu1776
Copy link
Author

frankliu1776 commented Jun 16, 2020

Hi Jennifer, thank you for the quick response.

Yes, the way you recreate my scenario is perfect. If the issue is not related with Chinese characters, could you find a way to fix it in cypress run? 👍

@adamalton
Copy link

I get the same problem (macOS 10.13.6, Cypress 4.8.0) and all of my JS files are in utf-8. The line numbers given in the terminal are always incorrect, but I can't see what the pattern is (it doesn't seem to be as simple as "off by 5" or anything like that). So they're consistently wrong, but there's no consistency to the wrongness 😃 .

I would be hugely grateful for a fix to this (or even if someone knows what the pattern is to translate them to the correct numbers), as currently it can make development quite frustrating sometimes! Screenshots of just one example below.

Screen Shot 2020-07-03 at 12 17 43
Screen Shot 2020-07-03 at 12 17 18

@frankliu1776
Copy link
Author

I get the same problem (macOS 10.13.6, Cypress 4.8.0) and all of my JS files are in utf-8. The line numbers given in the terminal are always incorrect, but I can't see what the pattern is (it doesn't seem to be as simple as "off by 5" or anything like that). So they're consistently wrong, but there's no consistency to the wrongness 😃 .

I would be hugely grateful for a fix to this (or even if someone knows what the pattern is to translate them to the correct numbers), as currently it can make development quite frustrating sometimes! Screenshots of just one example below.

Screen Shot 2020-07-03 at 12 17 43
Screen Shot 2020-07-03 at 12 17 18

thanks for replying, the same issue I am facing...

@numo-aiton
Copy link

Any progress on this Issue? I am running version 5.2.0 and I am still seeing this problem.

I created a simple test that will always fail. If I click the View stack trace link, the correct line of the spec file is reported ( in this case, it is off by one because it doesn't appear to take empty lines in the spec file into account ). If I click the Print to console button, the line of the spec file reported in the console log output is wildly incorrect.

Not sure if it's relevant, but the console output refers to a http uri, while the View stack trace output refers to a webpack uri.

Attached are screenshots

spec_file
failure
console_log

@jennifer-shehane jennifer-shehane changed the title Stack trace log(failed line number) printed in terminal(on Mac) is different from the stack trace on tool(cypress open) Stack trace log (failed line number) printed in cypress run is different from the stack trace in cypress open Jan 12, 2021
@nishant-shah-social
Copy link

I am also facing this issue and is tremendously frustrating for the dev team.
I personally feel that correct stack trace is a really important way of tracking the root cause of the issue and if it is incorrect than loads of time is required to be spent in debugging :(
Request to prioritise this bug and address it Soon please.
This is super useful when tests are been executed in headless mode and most of the times they are executed that way.
OR at least give us a formula to calculate the correct line number (if any such formula exists) :)

@zwass
Copy link

zwass commented Sep 26, 2021

@jennifer-shehane any update on this?

We are facing failures in CI with references to line numbers in the file that are beyond the length of the file.

The relevant files are using ASCII encoding.

@jcom000
Copy link

jcom000 commented Jan 31, 2022

Facing a similar issue with discrepancy between CI and local. I dunno if my files specify encoding at all.

      at Context.eval (https://cloud.astronomer-dev.io/__cypress/tests?p=cypress/integration/e2e/create-variable-apikey-run-dags.js:464:36)

image

$ file -i *
create-deploy.js:                   regular file
create-variable-apikey-run-dags.js: regular file

@kocoten1992
Copy link

As I run multiple cy.should, when cypress report the wrong line, I really don't know where the real error come from, so frustrating 😱

@tptech
Copy link

tptech commented Jul 28, 2022

This is a major problem with sporadic failures in our CI build. That the run command does not provide a representative stack trace to locate the problem is a major draw back to using Cypress - I'm not kidding. The lack of resolution of the failing statements within the test code is excruciating.

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Sep 9, 2022

The code for this is done in cypress-io/cypress#23575, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Sep 13, 2022

Released in 10.8.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v10.8.0, please open a new issue.

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators Sep 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.