Recursive function inside Effect.run(_:)

[nikitamounier]

Hello there!

I have a question on the behaviour of the Effect.run(_:) function. Basically, I'm using the Network framework in my app for some peer-to-peer functionality. Therefore, I've modelled all my dependencies in the TCA way, including a ConnectionClient, which represents the bi-directional connections the devices will have. It looks like this:

public struct ConnectionClient {
    public enum Event {
        case stateUpdated(NWConnection.State)
        case receivedMessage(type: MessageType, data: Data)
        case receivedMessageError
    }
    
    public var create: (_ id: AnyHashable, _ connection: NWConnection) -> Effect<Event, Never>

    public var startConnection: (_ id: AnyHashable) -> Effect<Event, Never>

    public var stopConnection: (_ id: AnyHashable) -> Effect<Never, Never>

    public var sendMessage: (_ id: AnyHashable, _ type: MessageType, _ content: Data) -> Effect<Never, Never>

    public var connectionExists: (_ id: AnyHashable) -> Bool

Then, with my .live implementation, I have a dictionary which holds all my connections:

public extension ConnectionClient {
    static var live: Self { /*...*/ }
}
private var connectionDependencies: [AnyHashable: NWConnection] = [:]

The create(_:_:) endpoint on the ConnectionClient is what initializes a connection and then sends back any state updates, while the startConnection(_:) endpoint is what starts the connection on a queue, and sends back any messages it receives.

Unfortunately, the API for receiving messages in the Network framework is quite weird. It looks like a pretty normal method on the surface, with a single callback closure parameter:

class NWConnection {
    func receiveMessage(completion: @escaping (_ completeContent: Data?, _ contentContext: NWConnection.ContentContext?, _ isComplete: Bool, _ error: NWError?) -> Void) { /*...*/ }
}

However, this function registers a handler for a single message, and then the handler will be discarded and therefore not used for any messages afterwards. So if we want to receive messages indefinitely, it's customary to use a recursive function to register an unlimited amount of handlers for an unlimited amount of messages.

So, I'm using a recursive function inside of my startConnection(_:) endpoint. The endpoint uses Effect.run since I want to send back an event whenever it receives a message. It looks like this:

extension ConnectionClient {
    static var live: Self {
        // ...
        return Self(
           // ...
            startConnection: { id in
                .run { subscriber in
                    let newQueue = GlobalQueues.p2pConnectionQueue()
                    connectionDependencies[id]?.start(queue: newQueue)
                    
                    func receiveNextMessage() {
                        connectionDependencies[id]?.receiveMessage { data, context, _, error in
                            if let message = context?.protocolMetadata(definition: TLVMessageProtocol.definition) as? NWProtocolFramer.Message {
                                subscriber.send(.receivedMessage(type: MessageType(rawValue: message.messageType) ?? .ping, data: data ?? Data()))
                            }
                            
                            if let error = error {
                                subscriber.send(.receivedMessageError)
                            } else {
                                receiveNextMessage()
                            }
                        }
                    }
                    receiveNextMessage()
                    
                    return AnyCancellable {}
                }
            },
            // ...
        )
    }
}    

Thing is, I'm not sure if this is allowed. I'm supposed to return an AnyCancellable in the Effect.run, but since I'm using a recursive function, won't it just never return until there is an error? Would there be another way of calling .receiveMessage(_:) indefinitely while still using the Effect.run function?

The full source code for the file can be found here.

Thanks!