[Host] Semaphore leak in ConcurrentMessageProcessorDecorator<TMessage>.ProcessMessage causes stalled consumers

[MaxNau]

Problem

User perspective

If message deserialization fails (invalid JSON schema) or user returns ProcessResult.Failure in error handler the consumer is stuck. No messages after failure arrive.

Tech perspective

ProcessMessage acquires the _concurrentSemaphore then returns early when a saved _lastException exists - but it does not release the semaphore. Repeatedly hitting this path leaks semaphore slots and eventually stalls message processing.

Repository / file

• SlimMessageBus.Host\Consumer\MessageProcessors\ConcurrentMessageProcessorDecorator.cs
• Affects methods: ProcessMessage, ProcessInBackground

Steps to reproduce

1. Configure a consumer with low concurrency (e.g. 1).
2. Cause a background ProcessInBackground to produce a ProcessMessageResult with Exception != null.
3. Call ProcessMessage — it will WaitAsync, observe _lastException, return Failure and never release the semaphore.
4. Repeat until all semaphore slots are consumed; processing stalls.

Actual behavior

Semaphore slots are not released on the early-return path and capacity is exhausted, stalling message processing.

Expected behavior

When returning early due to a saved exception, the semaphore must be released before returning so slots are not leaked.

Root cause

Early-return after await _concurrentSemaphore.WaitAsync(...) without a corresponding Release() — normal Release() runs only in ProcessInBackground finally.

[MaxNau]

Could this be fixed as soon as possible? This semaphore leak can stall consumers, not sure why this wasn't reported previously.

[zarusz]

Thanks for reporting. I will have a look.

[zarusz]

Hi @MaxNau,

There’s a pre-release version 3.3.5-rc101 available — could you give it a try and let us know if the issue still occurs?

Also, could you share a bit more about your setup?
For example, are you using the Redis transport and requiring consumer concurrency greater than 1?

[MaxNau]

Hi @zarusz,
Thank you for your prompt response and the action taken!

I can confirm that the issue is fixed.

The setup uses RMQ and a consumer with a concurrency of 1, but the problem also affected consumers with higher concurrency. It just required more exceptions to occur for all of them to become stale