Closed ssssarah closed 8 months ago
Is there a reason not to have a global TIMEOUT variable, that could be overwritten for each case? should it be accesible to be changed by the user?
Is there a reason not to have a global TIMEOUT variable, that could be overwritten for each case? should it be accesible to be changed by the user?
I would think this offers flexibility and that different implementations may go for their own timeout, ex: fetching a file could have a different timeout than having a response with json in the body.
The flexibility can still be kept by having each location have their own local variable that gets (for now) as its value the default one set somewhere else. Should one want to change its value, only the file/class local variable would need to be overridden, the request implementation wouldn't need to be changed and the global default variable wouldn't need to be changed either.
Attention: 5 lines
in your changes are missing coverage. Please review.
Comparison is base (
fc39f07
) 74.51% compared to head (79bd75e
) 74.55%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
There have been some issues recently in order to access some things hosted on github.io (ex: metadata context) (they should be fixed by the time of this review), and it's brought out one issue in forge: there were no timeouts when making requests, and some forge calls could hang for close to 10 minutes before getting an error that the server could not be reached.
This MR sets a timeout of 60 seconds for every request call in the codebase (constants are set in the different parts of forge that make requests, so that they may be changed depending on the use case)