Looking at ActiveHandlerTrackingEntry.Timer_Tick() -- the callback (= this method) is called only if it won the race with ActiveHandlerTrackingEntry.Dispose(). That means, if we are already within this method:

1. we've acquired ownership of the object
2. ActiveHandlerTrackingEntry.Dispose() is now a no-op

Thus, even if factory's Dispose() has already started (= _disposed is true), it is unfortunately in situation where it won't be able to do anything about this entry. We are the ones responsible.

The more I look at it, the more I think it is somehow more complicated than it should be

if we could guarantee that Dispose is only ever called when the entry is not within the collection anymore, we could even just null out the handler reference (via compare exchange obviously), so technically it shouldn't be touched by the CreateClient anymore? But what if it got retrieved there just before it was removed and about to be disposed?

thinking more, while it was guaranteed previously that the handler will remain alive while it's still being used - it is now broken, but only at the moment of factory disposal. and factory's (and transitively active entry's) dispose is only ever called during the full container dispose. meaning, this is a time when it becomes erroneous to use anything created by this container anymore. so this race - as any other errors during - is smth that can be expected. but I think just in case we should still play nice and throw ODE in the property getter instead of leaving it for a subsequent NRE.

you know what? I definitely was overthinking this.
let's remove IDisposable interface from both active and expired entries, it just makes things more complicated.

then, from active entry's perspective, it immutable with exception of the timer. from expired entry perspective, it's completely immutable.

the most straightforward approach to Factory's dispose would be:

1. mark factory as disposed. after that, no public methods should be able to reach the active handler collection. meaning, no new timers should be started after it.
2. we brush the active handlers so all the timers are stopped, AND all the conversions are completed => everything is in the expired queue now. not the best thing perf-wise, but it's full container disposal, so we might want to favor simplicity more here.
3. add parameter "force" to the expired cleanup. checks are only done with force=false (ordinary cleanup), for force=true (dispose) everything is cleaned by kipping the check.

from thread-safety perspective:

• external approach stopped -> nothing new can be added to active entries
• all remaining active entries are converted -> nothing new can be added to expired entries
• all expired handlers are disposed
  all these steps will be sequential.

here as well. what's more, if the _disposed got changed after the if check above but before _expiredHandlers.Enqueue, we can end up in the situation where Dispose believes it has cleared the queue, but this callback will add it just after.

one of the possible solutions would be to null out the _expiredHandlers reference completely on dispose, same as with active entry

this is wrong. this either should be already checked by the caller, or the caller wants everything to be disposed regardless

when we fix entry's Dispose to remove the redundant CanDispose check, it should be enough to just dispose the entry here.