Skip to content
This repository has been archived by the owner on Feb 25, 2022. It is now read-only.

fix(dispatch): upgrade to helix-fetch v2 #398

Merged
merged 5 commits into from
Feb 9, 2021
Merged

fix(dispatch): upgrade to helix-fetch v2 #398

merged 5 commits into from
Feb 9, 2021

Conversation

tripodsan
Copy link
Contributor

No description provided.

@codecov
Copy link

codecov bot commented Feb 4, 2021

Codecov Report

Merging #398 (adbd1df) into main (90af496) will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff            @@
##              main      #398   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            5         5           
  Lines          232       242   +10     
=========================================
+ Hits           232       242   +10     
Impacted Files Coverage Δ
src/fetchers.js 100.00% <100.00%> (ø)
src/index.js 100.00% <100.00%> (ø)
src/redirects.js 100.00% <100.00%> (ø)
src/utils.js 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 90af496...adbd1df. Read the comment docs.

},
"devDependencies": {
"@adobe/eslint-config-helix": "1.1.3",
"@adobe/helix-deploy": "https://github.com/adobe/helix-deploy.git#no-epsagon",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great!

@github-actions
Copy link

github-actions bot commented Feb 4, 2021

This PR will trigger a patch release when merged.

@@ -51,7 +49,7 @@ function getFetchOptions(options) {
delete headers.host;
delete headers.connection;
return {
cache: 'no-cache',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This cache option was never supported by helix-fetch (v1 & v2). Using the correct cache: 'no-store' option causes the following test failure:

1) Index Tests
       index produces 404 when fetcher fails due to missing action (with 404 handler).:
     TypeError: Stream had error: The operation was aborted.

The same error was also triggered with helix-fetch v1 but was hidden due the incorrect cache option.

Seems like this code is responsible for the failure:
https://github.com/adobe/helix-dispatch/blob/helix-v2/src/index.js#L227-L232

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no. this error was due to another problem: for the 404 page, we receive a 200 status, but need to tweak it to look like a 404. with helix-fetch v1, we could just override the response.status but with v2 this is protected (even worse, the object is not frozen, so no error is thrown, but even if you set res.status=404, it remains 200). so we wrap it with a Proxy to override the status. later in the finally block, it aborts all pending requests, if they are have not produced the response that is returned. since the proxied response is now not the same response again that we check against, it was aborted.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, I debugged the test with helix-fetch v1 and cache: 'no-store'. I got the exact same failure (aborted). So it doesn't seem to be related to v2 vs v1.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm... AFAICR, I added the Proxy recently, as I couldn't overwrite the status.... but I think it was for the universal deploy changes. this code is so complicated, there might be several layers of potential errors :-(

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so we wrap it with a Proxy to override the status

Why not

const { headers, url } = resp;
const resp404 = new Response(res.body, { status: 404, headers, url });

?

Copy link
Contributor Author

@tripodsan tripodsan Feb 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I try... but the problem remains, it's not the same response as we captured during the fetch. so we don't know if we need to abort or not.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but with v2 this is protected (even worse, the object is not frozen, so no error is thrown, but even if you set res.status=404, it remains 200)

FWIW: I agree, it is confusing. However it's the same behavior as with the most popular nodejs fetch implementation (node-fetch, 21m weekly downloads) and in the browser.

@stefan-guggisberg
Copy link
Contributor

related: adobe/helix-home#182

@tripodsan
Copy link
Contributor Author

now with the recent fixes, it hangs again on openwhisk (and epsagon)....

@tripodsan
Copy link
Contributor Author

now with the recent fixes, it hangs again on openwhisk (and epsagon)....

looking into it....

@tripodsan tripodsan self-assigned this Feb 5, 2021
@stefan-guggisberg
Copy link
Contributor

now with the recent fixes, it hangs again on openwhisk (and epsagon)....

hmm, just pulled the latest changes and run npm test:

64 passing (12s)

----------------------|---------|----------|---------|---------|-------------------
File                  | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
----------------------|---------|----------|---------|---------|-------------------
All files             |     100 |      100 |     100 |     100 |                   
 fetchers.js          |     100 |      100 |     100 |     100 |                   
 index.js             |     100 |      100 |     100 |     100 |                   
 redirects.js         |     100 |      100 |     100 |     100 |                   
 resolve-preferred.js |     100 |      100 |     100 |     100 |                   
 utils.js             |     100 |      100 |     100 |     100 |                   
----------------------|---------|----------|---------|---------|-------------------

No hanging tests.

@tripodsan
Copy link
Contributor Author

No hanging tests.

yes. but it hangs on openwhisk and espagon enabled...

eg:

$ curl -sD - 'https://adobeioruntime.net/api/v1/web/helix/helix-services/dispatch@4.4.7-test?static.owner=trieloff&static.repo=helix-demo&static.ref=master&path=/index.md&content.owner=trieloff&content.repo=helix-demo&content.ref=master&a=7'
HTTP/2 202
content-length: 86
content-type: application/json
x-request-id: mbt3f5GRZQYfxvzkGnB3k3saFYRhAeIa
access-control-allow-origin: *
access-control-allow-methods: OPTIONS, GET, DELETE, POST, PUT, HEAD, PATCH
access-control-allow-headers: Authorization, Origin, X-Requested-With, Content-Type, Accept, User-Agent
x-openwhisk-activation-id: 788c55c7f66b45a78c55c7f66b25a763
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
strict-transport-security: max-age=7884000; includeSubDomains
x-envoy-upstream-service-time: 60036
x-azure-ref: 07AYdYAAAAAAUWSsDaswjRJ27zsPVI0tOVFlPMDFFREdFMDQyMABiNzdiNjYzMy04ZjcwLTQyNWItOTJiZC03NmFlYmU5YWI5YzU=
date: Fri, 05 Feb 2021 08:51:51 GMT

{
  "code": "mbt3f5GRZQYfxvzkGnB3k3saFYRhAeIa",
  "error": "Response not yet ready."
}

It's hard to debug - I don't think it's related to helix-fetch, as we had this problems before. but rather with the promise-wars inside helix-dispatch :-) - or a new behaviour of epsagon....

@tripodsan
Copy link
Contributor Author

using a slightly modified epsagon would resolve the hanging actions: epsagon/epsagon-node#428

@stefan-guggisberg
Copy link
Contributor

@tripodsan 3 branch-deploy tests are still timing out. Any idea?

@tripodsan
Copy link
Contributor Author

@tripodsan 3 branch-deploy tests are still timing out. Any idea?

as I said... I'm still waiting for the espagon release...

@tripodsan tripodsan merged commit ac929cb into main Feb 9, 2021
@tripodsan tripodsan deleted the helix-v2 branch February 9, 2021 08:32
trieloff pushed a commit that referenced this pull request Feb 9, 2021
## [4.4.8](v4.4.7...v4.4.8) (2021-02-09)

### Bug Fixes

* **dispatch:** upgrade to helix-fetch v2 ([#398](#398)) ([ac929cb](ac929cb))
@trieloff
Copy link
Collaborator

trieloff commented Feb 9, 2021

🎉 This PR is included in version 4.4.8 🎉

The release is available on:

Your semantic-release bot 📦🚀

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

Successfully merging this pull request may close these issues.

None yet

3 participants