When a client initiates a subscription request it can be placed in the buffered channel waiting for processing by the hub's event loop. If the hub is cancelled while the subscription is waiting, then the routine attached to the subscription is orphaned and the client is never notified of subscriber-close.

This should be rearchitected so that subscribing clients can always be assured their channel will be closed upon hub cancellation.

Interleaving may happen between publishers or subscribers, but for a given pub/sub pair, messages should always be delivered in-order. This is not currently working.

Currently subscriber.Send doesn't respect ctx.Done(). This should be fixed.

Likely a race-condition. Haven't touched this in a while and I suspect the logic to be broken (especially since underlying libraries / language may have adjusted semantics in the interim).

--- FAIL: TestHubCancellationClosesSubscription (4.00s)
hub_test.go:152: Timed out (4s) waiting for cancel() to propagate to subscriber.
FAIL
FAIL github.com/akesling/arke/interchange 4.015s

The system currently uses a fixed-threshold, global-pause, collection methodology which is has expense proportional to the size of the topic trie. This has the potential to cause long pauses for large tries.

The other naive alternative is to collect a subscriber whenever it dies, but this has the potential to cause topic-collapsing of arbitrary complexity at time of subscriber-death and could thus also starve out publications.

The real solution to this should be to allow concurrent collection in the topic trie, preferably in a way that orthogonal new subscriptions aren't blocked by active collection.