Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: polling in proxy repository now stops correctly (#3268)
### What This patches two very subtle bugs in the proxy repository that cause it to never actually stop polling the db in the background ## Details - Issue 1 We've recently started to get the following output when running `yarn test`: ` Attempted to log "Error: Unable to acquire a connection at Object.queryBuilder (/home/simon/dev/unleash/node_modules/knex/lib/knex-builder/make-knex.js:111:26)` This seems to occur for every test suite after running the proxy tests and the full stack trace doesn't point to anything related to the running tests that produce this output. Running a `git bisect` points to this commit: 6e44a65 being the culprit but I believe that this may have surfaced the bug rather than causing it. Layering in a few console logs and running Unleash, seems to point to the proxy repository setting up data polling but never actually terminating it when `stop` was called, which is inline with the output here - effectively the tests were continuing to run the polling in the background after the suite had exited and jest freaks out that an async task is running when it shouldn't be. This is easy to reproduce once the console logs are in place in the `dataPolling` function, by running Unleash - creating and deleting a front end token never terminates the poll cycle. I believe the cause here is some subtlety around using async functions with timers - stop was being called, which results in the timer being cleared but a scheduled async call was already on the stack, causing the recursive call to resolve after stop, resurrecting the timer and reinitializing the poll cycle. I've moved the terminating code into the async callback. Which seems to solve the problem here. ## Details - Issue 2 Related to the first issue, when the proxy service stops the underlying Unleash Client, it never actually calls destroy on the client, it only removes it from its internal map. That in turn means that the Client never calls stop on the injected repository, it only removes it from memory. However, the scheduled task is `async` and `unref`, meaning it continues to spin in the background until every other process also exits. This is patched by simply calling destroy on the client when cleaning up ## The Ugly This is really hard to test effectively, mostly because this is an issue caused by internals within NodeJS and async. I've added a test that reads the output from the debug log (and also placed a debug log in the termination code). This also requires the test code to wait until the async task completes. This is horribly fragile so if someone has a better idea on how to prove this I would be a very happy human. The second ugly part is that this is a subtle issue in complex code that really, really needs to work correctly. I'm nervous about making changes here without lots of eyes on this
- Loading branch information