badeball / cypress-cucumber-preprocessor

Run cucumber/gherkin-syntaxed specs with Cypress
MIT License
1.32k stars 147 forks source link

21.0.0 regression: requests to __cypress/tests?p=* hang indefinitely #1243

Open cascornelissen opened 1 day ago

cascornelissen commented 1 day ago

Current behavior

Tests are hanging because requests to __cypress/tests?p=* are in pending state indefinitely.

Desired behavior

Tests don't hang

Test code to reproduce

The only thing we changed was updating to @badeball/cypress-cucumber-preprocessor@21.0.0, works as expected with 20.1.2. We're not using the browserify preprocessor or cypress-cucumber-diagnostics mentioned as breaking changes in the release notes.

I'll look into a reproducible example and additional logging tomorrow but wanted to report the issue already in case others run into it.

Versions

Checklist

badeball commented 1 day ago

Closing as not reproducible. You can open up another ticket when you can provide it.

cascornelissen commented 1 day ago

Fine with me 👍🏼

I'll dump some more information in this issue while debugging. Looks like the [filepart] resolving changed between these versions which might be related to #1196 or maybe #1225 :eyes: Also, the version logged for implicitIntegrationFolder seems to have changed.

21.0.0

  cypress-cucumber-preprocessor resolved environment overrides {
  cypress-cucumber-preprocessor   stepDefinitions: [
  cypress-cucumber-preprocessor     'integration/**/[filepart]/index.ts',
  cypress-cucumber-preprocessor     'integration/common/**/*.ts'
  cypress-cucumber-preprocessor   ]
  cypress-cucumber-preprocessor } +15s
  cypress-cucumber-preprocessor resolved no explicit user configuration +0ms
  cypress-cucumber-preprocessor resolved configuration {
  cypress-cucumber-preprocessor   stepDefinitions: [
  cypress-cucumber-preprocessor     'integration/**/[filepart]/index.ts',
  cypress-cucumber-preprocessor     'integration/common/**/*.ts'
  cypress-cucumber-preprocessor   ],
  cypress-cucumber-preprocessor   messages: { enabled: false, output: 'cucumber-messages.ndjson' },
  cypress-cucumber-preprocessor   json: { enabled: false, output: 'cucumber-report.json' },
  cypress-cucumber-preprocessor   html: { enabled: false, output: 'cucumber-report.html' },
  cypress-cucumber-preprocessor   pretty: { enabled: false },
  cypress-cucumber-preprocessor   usage: { enabled: false, output: 'stdout' },
  cypress-cucumber-preprocessor   filterSpecsMixedMode: 'hide',
  cypress-cucumber-preprocessor   filterSpecs: false,
  cypress-cucumber-preprocessor   omitFiltered: false,
  cypress-cucumber-preprocessor   implicitIntegrationFolder: 'integration',
  cypress-cucumber-preprocessor   isTrackingState: false,
  cypress-cucumber-preprocessor   dryRun: false
  cypress-cucumber-preprocessor } +0ms
  cypress-cucumber-preprocessor resolving step definitions using template(s) [ 'integration/**/[filepart]/index.ts', 'integration/common/**/*.ts' ] +0ms
  cypress-cucumber-preprocessor replacing [filepath] with '../../../../../test/cypress/integration/smoke-test' +1ms

Then, when pressing Ctrl+C to stop the process, the following is also logged

GET /__cypress/tests?p=integration/smoke-test.feature - - ms - -
GET /__cypress/tests?p=support/end-to-end.ts - - ms - -

20.1.2

  cypress-cucumber-preprocessor resolved environment overrides {
  cypress-cucumber-preprocessor   stepDefinitions: [
  cypress-cucumber-preprocessor     'integration/**/[filepart]/index.ts',
  cypress-cucumber-preprocessor     'integration/common/**/*.ts'
  cypress-cucumber-preprocessor   ]
  cypress-cucumber-preprocessor } +9s
  cypress-cucumber-preprocessor resolved no explicit user configuration +0ms
  cypress-cucumber-preprocessor resolved configuration {
  cypress-cucumber-preprocessor   stepDefinitions: [
  cypress-cucumber-preprocessor     'integration/**/[filepart]/index.ts',
  cypress-cucumber-preprocessor     'integration/common/**/*.ts'
  cypress-cucumber-preprocessor   ],
  cypress-cucumber-preprocessor   messages: { enabled: false, output: 'cucumber-messages.ndjson' },
  cypress-cucumber-preprocessor   json: { enabled: false, output: 'cucumber-report.json' },
  cypress-cucumber-preprocessor   html: { enabled: false, output: 'cucumber-report.html' },
  cypress-cucumber-preprocessor   pretty: { enabled: false },
  cypress-cucumber-preprocessor   filterSpecsMixedMode: 'hide',
  cypress-cucumber-preprocessor   filterSpecs: false,
  cypress-cucumber-preprocessor   omitFiltered: false,
  cypress-cucumber-preprocessor   implicitIntegrationFolder: '<snip>/test/cypress/integration',
  cypress-cucumber-preprocessor   isTrackingState: false
  cypress-cucumber-preprocessor } +0ms
  cypress-cucumber-preprocessor resolving step definitions using template(s) [ 'integration/**/[filepart]/index.ts', 'integration/common/**/*.ts' ] +0ms
  cypress-cucumber-preprocessor replacing [filepath] with 'smoke-test' +0ms
  cypress-cucumber-preprocessor replacing [filepart] with [ 'smoke-test' ] +0ms
  cypress-cucumber-preprocessor for 'integration/smoke-test.feature' yielded patterns [
  cypress-cucumber-preprocessor   'integration/**/smoke-test/index.ts',
  cypress-cucumber-preprocessor   'integration/**/index.ts',
  cypress-cucumber-preprocessor   'integration/common/**/*.ts'
  cypress-cucumber-preprocessor ] +1ms
  cypress-cucumber-preprocessor found step definitions [ 'integration/index.ts' ] +4ms
GET /__cypress/tests?p=support/end-to-end.ts 200 11623.842 ms - -
GET /__cypress/tests?p=integration/smoke-test.feature 200 14105.799 ms - -
GET /__cypress/runner/fonts/fa-solid-900.woff2 200 9.465 ms - 126828
cascornelissen commented 15 hours ago

Looks like it's getting stuck in this do loop.

https://github.com/badeball/cypress-cucumber-preprocessor/blob/2a3ea39b9af658df9936fd8b3eb7827445a6853f/lib/step-definitions.ts#L48-L52

21.0.0

This results in an infinite loop, as parts keeps getting extend with longer and longer combinations of ../

../../../../../test/cypress/integration/smoke-test
../../../../../test/cypress/integration
../../../../../test/cypress
../../../../../test
../../../../..
../../../../../..
../../../../../../..
../../../../../../../..
../../../../../../../../..
../../../../../../../../../..
../../../../../../../../../../..
../../../../../../../../../../../..
../../../../../../../../../../../../..
../../../../../../../../../../../../../..
../../../../../../../../../../../../../../..
../../../../../../../../../../../../../../../..

// ...

This might be related to our setup where the Cypress configuration is stored in a shared package (so ends up at <project>/node_modules/@company/<package>/cypress/config.js while the feature files are located at <project>/test/cypress 🤔

20.1.2

Conclusion

It looks like implicitIntegrationFolder was an absolute path on 20.1.2 and is just the directory name on 21.0.0 for some (yet unknown) reason, which causes an infinite loop when the paths don't have a common ancestor without ../.

cascornelissen commented 15 hours ago

@badeball, apologies for tagging you, but I have a really hard time creating a reproducible example because of the configuration-inside-a-shared-package setup on our side. Does the information in my previous comment ring any bells for you, before I spend a few more hours trying to debug the diff between 20.1.2 and 21.0.0 myself.

I also haven't set this up on our side myself so I'm trying to debug in two codebases I don't know much about 😅

badeball commented 8 hours ago

spend a few more hours

It should take you no such time to reproduce a folder structure and yes, that is what you should do.

badeball commented 8 hours ago

I'm trying to debug in two codebases I don't know much about

A reproducible example doesn't involve you diving into this code base. You should just take any of the examples, make the tiniest modification possible so that it reproduces the error, then share that example with me.

gscandola commented 7 hours ago

Hi there 👋 ,

I've faced this issue this morning too, I do not know what is the awaited format of this reproducible example, I've forked this repo and created a PullRequest to emphase the requirements to face the same issue: https://github.com/badeball/cypress-cucumber-preprocessor/pull/1244.

Once you've cloned this repo and switch to the PR branch simply:

The infinite loop seems to be reproduced when the config file of cypress is in a nested folder (I do not know why). the difference between the 2 scripts is only the config file location, content of these files is identical.

Thanks to @cascornelissen investigation I confirm that in the buggy case scenario the do/while loop is done infinitively.

OleksiiKachan commented 6 hours ago

I have same issue. but I noticed that just reverting the update for preprocessor did not fix the issue. since I did update cypress from 13.14.2 to 13.15.0 same day, I tried reverting that change as well. and now my tests are back. not sure if it is just cypress-cucumber-preprocessor or cypress did some nasty update as well 🤔

gscandola commented 6 hours ago

On my side the buggy case happened on a cypress 13.14.2, but also reproduced here with a 13.5.0

cascornelissen commented 5 hours ago

I don't want to derail this issue into an off-topic discussion but it feels wrong to me not to reply to this.

spend a few more hours

It should take you no such time to reproduce a folder structure and yes, that is what you should do.

I said I didn't want to spend a few more hours of debugging the codebase if you just happened to know what the root cause for this issue was, or could at least point me into some direction. I've tried to create a reproducible example, I failed. I also couldn't test specific commits because installing directly from GitHub doesn't work for this package.

Maybe you're right and it shouldn't take me that much time but for someone who doesn't know this project, its codebase, and how its implemented on our side, it was hard to create a setup that reproduces the issue I am facing.

I'm trying to debug in two codebases I don't know much about

A reproducible example doesn't involve you diving into this code base. You should just take any of the examples, make the tiniest modification possible so that it reproduces the error, then share that example with me.

As said, I tried that and failed to create a reproducible example and because of that I took a dive into the codebase, to try and figure out what might be causing it, so that I could provide a reproducible example.

Either way, I'm glad I'm not the only one and that there's a reproducible example and that my digging wasn't in vain. Hoping that the fix is easy 🤞🏼


On the off-chance that this will be interpreted the wrong way, and I truly understand where you're coming from as I also manage a few (smaller) npm packages for which issues get created with no information: please also think about the way your messages will be interpreted by others. You have every right to close issues and communicate in the way you want, but please realize that others are also just trying to help out and figure out where things are going wrong. The (online) world is hostile enough as it is already 😞