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

Clarify the behaviour of Javascript Validation when we are waiting for the full body #38

Open
sefeng211 opened this issue Jan 3, 2023 · 1 comment

Comments

@sefeng211
Copy link

There is test which expects the window.fetch to be resolved while the server is sending the response. If ORB is compatible with this behaviour, then it means ORB will allow the promise to resolve before it has made its decision about this request, otherwise this test would hang because ORB will wait for the full response indefinitely.

This contradicts to The promise should throw if it's blocked by ORB.

The current spec text for consuming the body stream for ORB is

Fully read response’s body given processBody and processBodyError
Wait for responseBodyBytes to be non-null.

Fully read response’s body given processBody and processBodyError would return a fully read body as promise and responseBodyBytes would be non-null when the full read body promise is resolved. So this is a blocking behaviour (thanks @annevk for clarifying this). However, this blocking behaviour contradicts to the test that I linked.

Should we allow the promise to be resolved first and only allow the body stream to be consumed if ORB allows this request?

Let me know if I misunderstand something.

@sefeng211 sefeng211 changed the title Confirm the behaviour of Javascript Validation when we are waiting for the response Clarify the behaviour of Javascript Validation when we are waiting for the response Jan 3, 2023
@sefeng211 sefeng211 changed the title Clarify the behaviour of Javascript Validation when we are waiting for the response Clarify the behaviour of Javascript Validation when we are waiting for the full body Jan 3, 2023
@annevk
Copy link
Owner

annevk commented Jan 4, 2023

I think you understood it correctly. I think we have to change the test. I suspect that instead of returning a response with an infinitely streaming body we'd instead hit a network timeout.

cc @jakearchibald

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jan 9, 2023
…l.any.js r=smaug

One of the subtests (Underlying connection is closed when aborting after
receiving response - no-cors) creates an fetch request with infinite
response, and it expects the promise of this fetch will be resolved
while the server is still responding, however, this behavior is
not compatible with ORB.

See annevk/orb#38 for more details.

I am disabling the JS validator for these tests, we could change
the ini file to mark them as TIMEOUT, since the test has
`// META: timeout=long`, it takes a very long time to timeout.

Once annevk/orb#38 is resolved, we
can enable the JS validator for them.

Differential Revision: https://phabricator.services.mozilla.com/D166180
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Jan 13, 2023
…l.any.js r=smaug

One of the subtests (Underlying connection is closed when aborting after
receiving response - no-cors) creates an fetch request with infinite
response, and it expects the promise of this fetch will be resolved
while the server is still responding, however, this behavior is
not compatible with ORB.

See annevk/orb#38 for more details.

I am disabling the JS validator for these tests, we could change
the ini file to mark them as TIMEOUT, since the test has
`// META: timeout=long`, it takes a very long time to timeout.

Once annevk/orb#38 is resolved, we
can enable the JS validator for them.

Differential Revision: https://phabricator.services.mozilla.com/D166180
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

2 participants