Skip to content

Fix OOM in Runner Node killing FLAME Pool - #87

Open
Lakret wants to merge 3 commits into
phoenixframework:mainfrom
Lakret:fix-runner-node-oom-killing-flame-pool
Open

Fix OOM in Runner Node killing FLAME Pool#87
Lakret wants to merge 3 commits into
phoenixframework:mainfrom
Lakret:fix-runner-node-oom-killing-flame-pool

Conversation

@Lakret

@Lakret Lakret commented Jul 8, 2026

Copy link
Copy Markdown

First reported in #66.

I have also encountered this error when testing my DinD backend for FLAME in one of my apps.

After further investigation, it seems that the issue is due to a race condition in FLAME.Pool.checkin_runner/4: if the caller is already dropped with the reason == :catch, the Pool process crashes with ArgumentError, which leads to the :ets table being absent for the following calls. Instead of crashing, this fix just executes maybe_drop_waiting/2 irrespective of the reason.

P.S. After fixing this issue, I noticed another issue: apparently FLAME Runner node going down can cause all other Runner nodes disconnecting due to prevent_overlapping_partitions logic in the :global module. It's outside the scope of this PR, but if you are encountering this issue, there are two ways to fix it:

  • disable this :global behavior via -kernel prevent_overlapping_partitions false in rel/vm.args.eex (if you are using releases to deploy)
  • make FLAME Runner nodes hidden (didn't test that one yet).

Overall, after testing the changes in this PR in my app, the original problem is solved - Pool doesn't crash on Runner's OOMs anymore.

@Lakret
Lakret marked this pull request as ready for review July 8, 2026 11:46
@Lakret
Lakret marked this pull request as draft July 8, 2026 12:14
@Lakret
Lakret marked this pull request as ready for review July 8, 2026 17:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant