Discussion: data/stream/rpc reliability

[pblazej]

Problem

Our data-related APIs do not (or indirectly) validate the state of their destinationIdentity which seriously impacts the reliability of such channels. It moves the responsibility to handle these state transitions to the consumer, respond to proper Participant lifecycle events, etc.

Reasoning about the order of events is impossible without server-side knowledge, handling all the combinations - highly impractical, and counter-intuitive (like participant already subscribed to a track, but cannot receive data from a data channel).

Consumers shouldn't be exposed to transport internals and their distributed nature. In most practical applications, we can just assume that if the Participant.Identity is returned somewhere, it's also "valid" for communication (regardless of the channel).

Swift Status Quo

Sending messages to inactive/non-existing participants will lead to:

• 🟡 room.localParticipant.performRpc - will timeout after 10s, but the API suggests:

    public enum BuiltInError {
        case connectionTimeout
        case responseTimeout // this is triggered
        case recipientDisconnected
        case sendFailed
        case recipientNotFound

• 🔴 room.localParticipant.publish(data:) - only checks publisher's own transport via publisherTransportConnectedCompleter - will return immediately
• 🔴 room.room.localParticipant.sendText and other streams - will just return immediately

Solution

Publisher

Always check for local transport, then await, reuse this part across 3+ APIs. This change is purely internal and should not break any existing behaviors.

Receivers

Add public option(s) to wait for the receivers with a consistent timeout, reuse this part across 3+ APIs. Technically, it's not super hard, as all the APIs are already async. New errors for opt-iners.

RPC example attached.

Questions

• Which modes do we really need?

  • The most practical one is just waitUntilActive (mirroring publisher side), forming Participant.Identity from String should not be that popular, so we assume the Participant exists somewhere among allParticipants already. If not, just throw immediately.

• "As soon as someone joins"

  • To handle that implicitly, we'd need an extremely long timeout, that could be covered by "joined event" → waitUntilActive sequence.

• How to handle multiple destinations (any/all = optimistic/pessimistic)?

  • Can we even predict the use cases here?

[pblazej]

Per our discussion with @lukasIO the bare minimum:

• wait until publisher active (that's more SDK bug than actual change)
• wait until receivers active
  • wait concurrently for each and every receiver → send
  • fail/throw if no one activates until timeout
  • success if at least one activates within timeout

[pblazej]

@bcherry @lukasIO we can introduce waitUntilActive() for the local participant, but:

• it must be called explicitly (no implicit benefits)
• it does not solve the problem of [Participant.Identity] - for multiple receivers, unless we choose the convention here (don't wait for all e.g.)

[lukasIO]

what's the benefit on having waitUntilActive on the local participant?

[pblazej]

what's the benefit on having waitUntilActive on the local participant?

No benefit, apart from what's actually implemented for data packets:

    func send(dataPacket packet: Livekit_DataPacket) async throws {
        func ensurePublisherConnected() async throws {

For remotes, as I said doing waitUntilActive() on a single Participant.Identity is also cumbersome, as all the APIs are based on `[Participant.Identity] - consumer needs to do the heavy lifting (fork, async stuff, etc.).