Skip to content

Conversation

@QuinnWilton
Copy link

@QuinnWilton QuinnWilton commented Feb 10, 2026

This is part of a set of 4 PRs that arose out of some static analysis tooling I'm working on:

That means that these aren't crashes or issues that I've observed in practice, however based on my reading of the code, they do represent issues worth addressing.

Problem:

Beams.apply_to_all/2 spawns its worker process using a bare spawn/1, and then blocks in block_until_done/3 until it receives a :progress message from it. If the worker crashes, this message will never arrive, and the caller will block indefinitely.

Solution

Replace spawn/1 with spawn_monitor/1, and add a receive clause in block_until_done/3 to handle the worker unexpectedly terminating before a :progress message is sent, so that we're able to immediately raise instead of blocking forever.

In the successful case, the monitor is flushed to avoid :DOWN messages building up and causing a mailbox leak.

Replace bare spawn with spawn_monitor in Beams.apply_to_all/2.
If the worker process crashed, the parent would hang forever
waiting for :progress messages that would never arrive.

Propagate the monitor ref through block_until_done and raise on
{:DOWN, ...} so crashes surface immediately. Demonitor on normal
completion.
@QuinnWilton QuinnWilton changed the title fix(forge): monitor beam rewriting coordinator process fix(forge): monitor beam rewriting worker process Feb 10, 2026
@QuinnWilton QuinnWilton force-pushed the fix/forge-beams-unlinked-spawn branch from 972329d to eb80bc2 Compare February 10, 2026 23:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants