Root Cause Found: Missing Demand Due to Hidden Recursive Call

After receiving valuable guidance from my manager TamLeDuc , I was able to identify the root cause behind the issue where handle_demand/2 was not being triggered, even though messages were continuously arriving.

Root Cause:
There was a hidden recursive call in the message handling logic that wasn’t immediately obvious. The function lacked a clear stopping condition and had no timeout mechanism, which led to:

• The process getting stuck in an infinite loop.
• It never returning control to receive incoming demands.
• Broadway not being able to push new demand, causing the system to appear frozen.

This was particularly tricky because it didn’t produce any crash or clear stacktrace. The process simply hung, leading to the false impression that the system was overloaded or disconnected.

Solution:

• Refactored the recursive logic to ensure controlled flow.
• Added limits or timeouts to prevent long waits.
• Placed logs at the start and end of handler functions to better detect processing bottlenecks in the future.

Thanks again to TamLeDuc for the direction and to everyone who took the time to look into this — your support helped save a lot of debugging hours!

And big thanks to everyone who stopped by or took a moment to read this post — I really appreciate your time and attention!

Hello,

Welcome to the forums

I’m tinkering with your app. I can observe packet loss when sending a million messages but the handler are called, meaning the demand is properly registered and served.

Now if the producer process is overloaded with UDP messages, as it is in active mode, it will take time to receive the demand messages.

Maybe you need more unit tests!