If the server uses Zap to replicate reliable events to the client including reference to an Instance, then deletes that Instance, there's no guarantee the client will receive that Instance as non-nil, because deletion will replicate before Zap replicates its event triggers. If developers could flush a Zap queue, triggering immediate RemoteEvent:FireClients, they could ensure that the Instance reference exists when received by the client because property writes replicate on the same ordering channel as reliable RemoteEvents.
Developers would be able to flush a queue immediately before deleting important Instances.
Implementation Details
Generate a casing variant of flush_queue(channel) where channel has type of a union of string singleton channel names.
Additional context
While developers can type Instances as optional, this is an awkward solution. The server may use Zap to inform clients that a round has ended, then delete the map. Until the Zap event trigger replicates, other client code won't expect the map to be deleted, even if Zap network callbacks see it's nil.
Channels would complement this. Instead of flushing one queue for all reliable events, only the relevant queues need to be flushed. While channels will allow disabling batching, in this case batching is still desirable most of the time.
I think this could be introduced before channels and still be useful.
Describe your feature
If the server uses Zap to replicate reliable events to the client including reference to an
Instance
, then deletes thatInstance
, there's no guarantee the client will receive thatInstance
as non-nil
, because deletion will replicate before Zap replicates its event triggers. If developers could flush a Zap queue, triggering immediateRemoteEvent:FireClient
s, they could ensure that theInstance
reference exists when received by the client because property writes replicate on the same ordering channel as reliableRemoteEvent
s.Developers would be able to flush a queue immediately before deleting important
Instance
s.Implementation Details
Generate a casing variant of
flush_queue(channel)
wherechannel
has type of a union of string singleton channel names.Additional context
While developers can type
Instance
s as optional, this is an awkward solution. The server may use Zap to inform clients that a round has ended, then delete the map. Until the Zap event trigger replicates, other client code won't expect the map to be deleted, even if Zap network callbacks see it'snil
.Channels would complement this. Instead of flushing one queue for all reliable events, only the relevant queues need to be flushed. While channels will allow disabling batching, in this case batching is still desirable most of the time.
I think this could be introduced before channels and still be useful.