Races and memory leak for ReceptionStatusAwaiter

[philipptrenz]

Hi all,

we hit a couple of issues with the current ReceptionStatusAwaiter implementation:

• Race on cleanup: both the waiter and receiver do del self.awaiting[...], which can lead to KeyError if they delete the same entry around the same time. Using pop(..., None) avoids this.
• Unbounded growth: self.received keeps every status forever, so it will grow without limit in long-running processes.

A clean fix would be to treat reception statuses as single-consumer: once awaited, remove them via pop(). That also makes the semantics simple: only one coroutine may await a given message_id.

Would it be acceptable to update the code with that assumption (single awaiter per message id), plus safe cleanup using pop()? If so, I'd have a PR ready.

If multiple awaiters are actually expected, we might have to look into a different approach (e.g. Futures/shared results).

FYI @realdognose @ReinvdZee

[lfse-slafleur]

@philipptrenz Thanks for flagging and proposing a solution! At the moment there is only a single consumer so using pop should be fine. Feel free to propose a PR and set me as the reviewer. I am quite familiar with that part of the code.

Could you ensure to change the docs of the function that we are assuming single consumer so we don't forget?

[lfse-slafleur]

@philipptrenz Feel free to put me in an @ or ping me on discord if you have an issue like this and you need a bit quicker help. Sorry it took me so long to respond to this! Missed the notification.