Over time we've observed that some events exist in a sort of no-mans-land.

When you stop the driver, they are not in the cache, but when you start the driver the event gets replayed (retried) anyway.

In this scenario:

1. An event in the subscriber thread in itp triggers a write-back modify to the source (ie the app)
2. The shim responds with a "retry" to the write-back
3. The subscriber thread re-submits the modify to the shim. As this was initiated in itp, it does not pass through otp at all so can't be intercepted by policy.

Rinse and repeat 15000+ times so far. It seem that until the shim returns success (or error or warning) this will never get past that event. All other events in subscriber queue just cache up.

We have't yet tried clearing the driver cache (this particular driver config doesn't tolerate resync very well). Had hoped we could veto out this individual event. but no luck.

Where we have seen this same behaviour before in another driver, the event passed at least through sub-ctp and otp so we could veto there.

Where does the engine keep track of this event?

This is the Notes shim.
However we saw similar behavior in SOAP shim when we implemented a fake polling routine which injected events into the pub-etp, if these triggered a subscriber thread reset (due to reset set in driver filter) and the driver was shutdown before the subscriber thread reset had completed, it would just loop over that event until we vetoed it.