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

Some XHRs loop infinitely since 3.3.1 #4668

Closed
flotwig opened this issue Jul 8, 2019 · 7 comments
Closed

Some XHRs loop infinitely since 3.3.1 #4668

flotwig opened this issue Jul 8, 2019 · 7 comments
Assignees

Comments

@flotwig
Copy link
Contributor

flotwig commented Jul 8, 2019

Current behavior:

I noticed the some of our API, mainly XHR requests were continuously getting looped indefinitely when i upgraded Cypress from 3.2.0 to 3.3.0. So we rolled it back.
Now we hit some other bugs, for which we wanted to upgrade to Cypress 3.3.1, once again i am getting a similar issue.

  1. For some of the tests some XHR requests are loading indefinitely.
  2. The Timer is not incrementing
  3. The Test Runner is not responding

cypress_1

cypress_2

cypress_3

------------ Configuration -------
{
animationDistanceThreshold: 5,
baseUrl: null,
blacklistHosts: null,
chromeWebSecurity: true,
defaultCommandTimeout: 20000,
env: {
CLIENT: 'demoaccount',
failOnSnapshotDiff: false},
execTimeout: 60000,
fileServerFolder: '',
fixturesFolder: 'cypress/fixtures',
hosts: null,
integrationFolder: 'cypress/integration',
modifyObstructiveCode: true,
numTestsKeptInMemory: 1,
pageLoadTimeout: 60000,
pluginsFile: 'cypress/plugins',
port: null,
reporter: 'spec',
reporterOptions: null,
requestTimeout: 5000,
responseTimeout: 30000,
screenshotsFolder: 'cypress/screenshots',
supportFile: 'cypress/support',
taskTimeout: 60000,
testFiles: '**/*.{spec.js,feature}',
trashAssetsBeforeRuns: true,
userAgent: null,
video: true,
videoCompression: 32,
videoUploadOnPasses: true,
videosFolder: 'cypress/videos',
viewportHeight: 660,
viewportWidth: 1000,
waitForAnimations: true,
watchForFileChanges: true}
-----------

Scenario failing- Validating the time/date picker yields a correct date in the calendar while scheduling email message (we are using cucumber library)

Desired behavior:

Things are fine in 3.2.0, except some known issues like forwarding of socket failures related error in HTTP api level, which causes some parse error (Internal Error 500) in cypress.

Steps to reproduce: (app code and test code)

I am sharing some snippet of the login code, which we use to login.

Cypress.Commands.add(
	'login',
	{
		prevSubject: 'true'
	},
	(client, user) => {
		cy.logout();
		return cy.visit(`${BASE_URL}`).then(() => {
			return cy.getCookie('csrftoken').then(({ value }) => {
				return cy
					.request({
						url: `${client.url}/accounts/login`,
						form: true,
						method: 'POST',
						body: {
							username: client.users[user].email,
							password: client.users[user].password,
							csrfmiddlewaretoken: value
						}
					})
					.then(() => client);
			});
		});
	}
);

Versions

cypress - 3.3.1
electron - 61
OS - Mac OS Mojave 10.14.5

Attachments

cy_3.3.0_debug.log
cy_3.3.1_debug.log


During my re-testing with version 3.3.2 i can see the same issue is occurring again and i confirm that this occurs only in electron.

One of the calls that (XHR) that kept looping was mark_as/ . I am attaching a HAR dump file for the network requests during the test. I hope that would be useful.

cypress.har.txt

p.s. Please rename cypress.har.txt to cypress.har if your HAR analyser needs that.

Originally posted by @joydeep100 in #4411 (comment)

@flotwig
Copy link
Contributor Author

flotwig commented Jul 8, 2019

@joydeep100 I looked at the HAR you supplied, but I can't find the XHR requests that you mentioned as looping. Specifically, in your test, it looks like the /api/v1/oauth2_connections endpoint is loading forever, but in the HAR there is no such URL being visited:

image

Also, is your blacklistHosts option still empty like in your original post? I notice that Google Adsense and Analytics, among others, appear to have been blocked:

image


I can't reproduce the issue you're running in to since 3.3.2. To get this solved, it would help me a lot if you could create an example repo that I can clone and run locally so I can see the problem first-hand and debug it.

@flotwig flotwig self-assigned this Jul 8, 2019
@flotwig
Copy link
Contributor Author

flotwig commented Jul 8, 2019

Potentially related (blacklisted HTTP requests never receiving response): #4656

@joydeep100
Copy link

joydeep100 commented Jul 8, 2019

@flotwig I have uploaded a video, so that you can see what i am able to see. I am not sure if I could share a reproducible code at this point. I am okay to do a screen share (maybe zoom ) to debug further any time this week before friday. If thats okay with you.

https://drive.google.com/file/d/1bKcIkowEg7vJ-pdDZs3Et9QKD54q0ugH/view?usp=sharing

@flotwig
Copy link
Contributor Author

flotwig commented Jul 8, 2019

@joydeep100 I don't have access to view that file. Nvm, works now. Do you think you could create a small example repo that does similar things to your test that showcases the bug occurring? It will be hard for me to debug without being able to reproduce the issue on my machine.

@joydeep100
Copy link

@flotwig I am pretty new to js and cypress :P I really doubt i would be able to create an example test for this. As this interaction is with our React based App.

@jennifer-shehane jennifer-shehane added the stage: needs information Not enough info to reproduce the issue label Jul 10, 2019
@joydeep100
Copy link

@flotwig @jennifer-shehane This issue got fixed in 3.4.1. I have tested it and works properly. Please close this.

@flotwig flotwig closed this as completed Jul 30, 2019
@flotwig flotwig removed the stage: needs information Not enough info to reproduce the issue label Jul 30, 2019
@rangrasjay
Copy link

Facing the same issue in 3.4.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants