RFC 0017 - Introducing a new EventSub transport type: Conduit

[ginovva320]

@prod

After a conduit is created, how long do we have before all shards need to be registered? And what are the consequences of not reaching the minimum shard count in that amount of time?

I think there may be a slight misunderstanding here. When a conduit is created, the shard count provided must be at least the minimum shard count.

Following the creation, the only time limit enforced is that if 0 shards are enabled for 72 hours, the conduit would be deleted. In practice, this means that after creating a conduit, you must update 1 shard with a transport within 72 hours.

Aside from that, the consequence of not updating the number of shards specified in your shard count is that you risk notifications being lost. The flow we’d recommend is: create the conduit with n shards, update n shards with n transports, create subscriptions pointing to the conduit. This would ensure no notifications are dropped.

@prod

Will it not be possible to disable a specific shard by its id? For example, I may want to conduct maintenance to one server with outstanding shards, but these may not be the most recently registered shards (e.g., in 0-50 rather than 50-99)

Correct, arbitrary shards cannot be disabled. In the specific scenario you’ve given, we’d recommend updating the shards with a new transport before taking those servers down for maintenance. Multiple shards can use the same transport.

@prod

Is it guaranteed that this notification would avoid disabled shards, unlike regular subscription types?

No, there won’t be special dispatching logic for this subscription type. We’d recommend that when subscribing to this subscription type, you supply a different transport type so that the disabled notification isn’t dependent on your conduit.