1) The debouncer does not respect MAX_QUEUED_EVENTS; it keeps enqueueing events past that threshold.
The reason is that the test for MAX_QUEUED_EVENTS gets bypassed by the test for OVERFLOW_WARNING_INTERVAL.
Additionally the counter should be decremented when an event is rejected.
This problem could create memory leak problems when events are arriving extremely fast.
2) In very rare situations, an event could remain in the debouncer queue; it would only be delivered if/when a new event arrives afterwards.
It happens when an immediate delivery cancels a previously running immediate delivery; if that happens while the previous delivery is about to finish, the new event that triggered the second immediate delivery will remain in the queue.
Here is a scenario that shows evidence of that:
Note: this problem might only happen when maxPendingEvents = 1, which is not realistic. But it makes our tests fail randomly.