Ran
|
Jobs
3
|
Files
9
|
Run time
5min
|
Badge
Embed ▾
README BADGES
|
travis-ci
Handle context between two async requests This commit fixes a bug where a request can end without finishing its timings. See: https://github.com/MiniProfiler/node/pull/4 Bug cause: The structure that is used to register Miniprofiler timing providers, like (Postgres, HTTP, Redis), because it overrides the original method (globally) and uses the `request` object to access the Miniprofiler extensions to build the timings, and this doesn't work in a scenario with simultaneous requests using an async provider. Here is an example using [`pg`](https://github.com/goenning/miniprofiler-pg/blob/master/index.js) to try illustrating the failing scenario (check out the `tests/concurrent-async-test.js` test to see it running). request A start: * `pg.Client.prototype.query` holds a `req` object of requestA. * It calls `.query` in a pg instance * A miniprofiler timing starts with the call to `req.miniprofiler.timeQuery(...)` * The original method is called (async). request B start: * `pg.Client.prototype.query` holds a `req` object of request B. * It calls `.query` in a pg instance * Start timing with `req.miniprofiler.timeQuery(...)` * The original method is called (async). request A resume: * The result of `.query` is returned * A new call to `.query` is made * This time the `req` points to request B, this means that `req.miniprofiler.timeQuery(...)` will start a timing on request B. * The original method is called (async) request B resume: * The result of `.query` is returned. * All data was fetched, the request is ready to finish, so internally Miniprofile calls [`stopProfilling`](https://github.com/MiniProfiler/node/blob/<a class=hub.com/MiniProfiler/node/commit/1a98e40698b1126ac8de728a33406656361f8870">1a98e4069/lib/miniprofiler.js#L80). * This fails because there is a timing started (by request A) but not finished, so calculating the [diffs](https://github.com/MiniProfiler/node/blob/1a98e40698b1126ac8de728a33406656361f8870/lib/miniprofiler.js#L409) will fails because... (continued)
96 of 98 branches covered (97.96%)
9 of 9 new or added lines in 1 file covered. (100.0%)
375 of 376 relevant lines covered (99.73%)
73.62 hits per line
ID | Job ID | Ran | Files | Coverage | |
---|---|---|---|---|---|
1 | 72.1 | 4 |
15.88 |
Travis Job 72.1 | |
2 | 72.2 | 4 |
15.88 |
Travis Job 72.2 | |
3 | 72.3 | 9 |
99.73 |
Travis Job 72.3 |
Coverage | ∆ | File | Lines | Relevant | Covered | Missed | Hits/Line | Branch Hits | Branch Misses |
---|