thumbor / thumbor / 38184548511

92%

push

github

fix(strict_https_loader): accept the request start time

http_loader.load passes the fetch start time to its return_contents_fn as
req_start, a keyword that 107b164d (2016) added to the HTTP loader's own
callback so it can record the fetch latency metric. When 3d5fbe93 (2020)
moved the loaders to async/await it started handing the strict HTTPS
loader's return_contents to http_loader.load as that callback, but the
function kept its three-parameter signature, so from then on every fetch
through the strict loader, successful or not, ended in a TypeError and the
request failed with a 500. The only path that still behaved was a URL
rejected by validate(), which returns before any fetch. The tests never
caught it because they only called return_contents directly with three
arguments. return_contents now takes req_start and forwards it to
http_loader.return_contents, so the strict loader records the same latency
metric as the HTTP loader.

The test file gains a direct call with req_start that checks the latency
metric is recorded, and an end-to-end test that serves a page over TLS with
Tornado's AsyncHTTPSTestCase and runs the strict loader's own validate()
and load() against it with certificate validation turned off, which is the
call path that failed. Both errored with the TypeError before the change.
Nothing changes for callers that omit req_start, which defaults to None as
it does in http_loader.

2 of 2 new or added lines in 1 file covered. (100.0%)

4467 of 4865 relevant lines covered (91.82%)

4.59 hits per line