TAP streams continue to do "work" after receiver has disconnected

Not sure if this is the right component...

We discovered this with the tap.py sample script, but Dustin assures me that it would happen elsewhere.

If a TAP receiver connects and starts a backfill, then disconnects, the backfill will still be going on and just throwing away the data. This can cause extra disk i/o as well as blocking other things in the queue from proceeding

Dustin says that this can be fixed by adding some logic in the "jobs" to evaluate whether their data is going to be consumed or not.