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

[frankliu1776]

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:
   
   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:
   

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]

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

[jennifer-shehane]

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]

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

   

   cypress run is incorrect line/column number 5:6

   

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')
   })

   

[frankliu1776]

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]

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.

[frankliu1776]

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.

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

[numo-aiton]

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

[nishant-shah-social]

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]

@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]

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)

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

[kocoten1992]

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]

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]

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]

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.