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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant