Fix races and memory leak in ReceptionStatusAwaiter#156
Conversation
|
@philipptrenz Thanks for pinging me! Sorry for the slow response after your ping, we were doing a task that was super high prio on our side. |
lfse-slafleur
left a comment
There was a problem hiding this comment.
I am okay with approving this for now. Be aware that the life cycle of a ReceptionStatus still has to be designed in S2 so we will have to revisit this in the future, but at least with your PR we won't have an ever growing list.
Edge cases will remain after this fix e.g. being able to check if a ReceptionStatus has been received in the past, how long should we keep it (currently if a ReceptionStatus is never awaited, it will remain in ReceptionStatusAwaiter indefinitely as well).
We should release this with a major version bump, because it will change the usage of this library significantly. I don't know of anyone who is relying on being able to receive the same ReceptionStatus multiple times, but it might break idempotency for some of our users.
|
@philipptrenz Released as |
This PR ensures that each
ReceptionStatuswill get removed after being consumed.Resolves #153