-
Notifications
You must be signed in to change notification settings - Fork 565
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
Fix fetch parameters not being applied correctly #1870
Conversation
Not sure how this directly undoes #1386 and the test still passes, will look into it and see if I am missing something obvious? |
lib/agent.js
Outdated
@@ -81,6 +81,10 @@ class Agent extends DispatcherBase { | |||
} | |||
} | |||
|
|||
options () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this seems a little hacky, any thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would need a bit more support from all the available agents.
Otherwise, I'm good with it.
@ronag @KhafraDev why is (I think I missed #1386, otherwise I would have objected then. It was a busy period of my life.). |
Codecov ReportBase: 90.35% // Head: 90.33% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1870 +/- ##
==========================================
- Coverage 90.35% 90.33% -0.02%
==========================================
Files 70 70
Lines 6042 6043 +1
==========================================
Hits 5459 5459
- Misses 583 584 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the fix here is simply that fetch doesn't pass it's own timeout values. Why do we override them in fetch?
They are overridden in fetch to match chrome's behavior. I agree that the fix is to remove them. edit: #1373 |
Do I need to adjust any defaults anywhere to preserve behavior or simply delete the 2 lines in lib/fetch/index.js? And remove my 300 sec test that was aiming to enforce the previous feature request? |
removing the 2 lines is fine, the other changes should also be removed |
Ok this is ready for a re-review, it was my original changeset as well until I realized it was undo-ing #1373 and #1386 If you want me to add the 300 second tests back in from my previous commit and change the defaults elsewhere in the agent, please let me know, but for now at least the ability to override in fetch exists/works and a test that makes sure of that is in (unless the default gets changed to a much larger number in the future) |
Oops sorry I didn't know clicking re-request review on a change request removes the other reviewers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM once test pass
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
lib/agent.js
Outdated
@@ -81,6 +81,10 @@ class Agent extends DispatcherBase { | |||
} | |||
} | |||
|
|||
options () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would need a bit more support from all the available agents.
Otherwise, I'm good with it.
@mcollina @ronag what happens if you set bodyTimeout and headersTimeout to 20 minutes, but do NOT set keepAliveTimeout (default is 10 minutes), and a request takes say 15 minutes. Looking at this code, it kind of looks to me like the request will just die and eventually timeout at the 20 minutes and return a bodyTimeout or headersTimeout. This is what I am experiencing (I know this is wack to have such long requests... but I am starting by just porting this request from axios which works)
I will increase setting keepAliveTimeout but am wondering if there is a more elegant way to handle this so that the errors I get make sense |
I'm failing to understand how that relates to this PR. If not, please open a new issue. |
Ok fair enough, I have little to no information to put in a new issue yet so was hoping to just get some guidance. I was hopeful that this PR fixed my long request issue and it does not, so to me there is something about undici that I continue to not understand for a long request. I am glad I was able to write a tangible test for this particular issue, so I will see if I can figure out how to write a test case for what I am still experiencing. |
This is why I thought it was related, because it allowed me to expose the next issue basically #1887 |
* Fix default fetch parameters * Preserve existing behavior with 300 second timeout if not defined * Add test for 300 second timeout as default * Cleanup old unused tests * Simplify how fetch utilizes timeouts from agent
* Fix default fetch parameters * Preserve existing behavior with 300 second timeout if not defined * Add test for 300 second timeout as default * Cleanup old unused tests * Simplify how fetch utilizes timeouts from agent
* Fix default fetch parameters * Preserve existing behavior with 300 second timeout if not defined * Add test for 300 second timeout as default * Cleanup old unused tests * Simplify how fetch utilizes timeouts from agent
Fixes #1864