Pavel/epd 1022 oom

[pavelflux]

---

labels: mergeable

Fixes: EPD-1022

Motivation and Context

There is quite a complex issue with OOM, best seen in e2e tests of the main repo.
For this to be fixed, we need to be able to stop polling manually via the EppoSDKClient.

Description

After adding eppo sdk client to api e2e tests in main repo (in this PR)
we started to hit OOM error (while running jest, locally or in GH Actions).
After some research I found out that eppo sdk is causing this issue.
My logic here is:

• init of EppoSDK starts polling which is done via recursive setTimeout calls.
• The recursion continues until poller.stop method is called;
• poller.stop method never called;
  Also, I saw the issue in this GH action: https://github.com/Eppo-exp/eppo/actions/runs/4043339513/jobs/6952139426

  ●  Cannot log after tests are done. Did you forget to wait for something async in your test?
    Attempted to log "Error polling configurations: connect ECONNREFUSED ::1:4000".

      at console.error (node_modules/@jest/console/build/BufferedConsole.js:127:10)
      at Timeout.poll [as _onTimeout] (node_modules/@eppo/node-server-sdk/src/poller.ts:27:15)


  ●  Cannot log after tests are done. Did you forget to wait for something async in your test?
    Attempted to log "Error polling configurations: connect ECONNREFUSED ::1:4000".

      at console.error (node_modules/@jest/console/build/BufferedConsole.js:127:10)
      at Timeout.poll [as _onTimeout] (node_modules/@eppo/node-server-sdk/src/poller.ts:27:15)


  ●  Cannot log after tests are done. Did you forget to wait for something async in your test?
    Attempted to log "Error polling configurations: connect ECONNREFUSED ::1:4000".

      at console.error (node_modules/@jest/console/build/BufferedConsole.js:127:10)
      at Timeout.poll [as _onTimeout] (node_modules/@eppo/node-server-sdk/src/poller.ts:27:15)

even if this does not lead to OOM issue itself, it prevents Jest from exiting. (Jest has an issue with OOM, which I fixed in the PR (ADD LINK TO PR HERE)

Also, please note that recursive setTimeout itself is OOM-prone, so if it was not for the jitter, I would replace it with setInterval.

@leoromanovsky @chasdevs maybe we can have another condition to stop the recursion?

How has this been tested?

Manually and via tests

[chasdevs]

I'd reshuffle the args but I'm OK with the change. Seems more ideal to not instantiate the eppo client altogether in our backend integration tests.

[chasdevs]

Probably better to add the param at the end, so anyone implementing this constructor doesn't have to reshuffle arg order.

[leoromanovsky]

ok let's try this way and see