Infinite Realtime Re-Subscribes after keeping the app open over night on macOS

[EduardMe]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

The Realtime library is re-subscribing infinitely, locking up the app. The subscribe function calls itself again when it runs into a try-catch error.

To Reproduce

Running my app with Supabase integration, logged in and connected to the realtime notifications over night on my Mac, it becomes occasionally unresponsive with infinite calls to the subscribe() func in the realtime library. The Mac is in sleep state and probably doesn't maintain a continuous stable internet connection.

Expected behavior

It should give up re-subscribing after an error after a few retries to prevent an infinite loop.

System information

• OS: macOS
• Version of supabase: 2.29.3

See some logging I could extract from XCode:
inifnite-resubscribe.txt

Debugging

XCode was still open and running luckily when it happened, so I could track it back to the original call. Find above also the extracted stack trace.

In the function from the RealtimeChannelV2 file, I can see it calls subscribe() and in the try/catch block it calls subscribe() again infinitely if the subscribe call times out. Ideally, it gives up or at least checks if the device is in sleep mode or has no connection or similar.

  public func subscribe() async {
    if socket.status != .connected {
      if socket.options.connectOnSubscribe != true {
        reportIssue(
          "You can't subscribe to a channel while the realtime client is not connected. Did you forget to call `realtime.connect()`?"
        )
        return
      }
      await socket.connect()
    }

    status = .subscribing
    logger?.debug("Subscribing to channel \(topic)")

    let joinConfig = RealtimeJoinConfig(
      broadcast: config.broadcast,
      presence: config.presence,
      postgresChanges: mutableState.clientChanges,
      isPrivate: config.isPrivate
    )

    let payload = RealtimeJoinPayload(
      config: joinConfig,
      accessToken: await socket._getAccessToken(),
      version: socket.options.headers[.xClientInfo]
    )

    let joinRef = socket.makeRef()
    mutableState.joinRef = joinRef

    logger?.debug("Subscribing to channel with body: \(joinConfig)")

    await push(
      ChannelEvent.join,
      ref: joinRef,
      payload: try! JSONObject(payload)
    )

    do {
      try await withTimeout(interval: socket.options.timeoutInterval) { [self] in
        _ = await statusChange.first { @Sendable in $0 == .subscribed }
      }
    } catch {
      if error is TimeoutError {
        logger?.debug("Subscribe timed out.")
        await subscribe() // <----- Called over and over again as the connection is timing out repeatedly in sleep mode 
      } else {
        logger?.error("Subscribe failed: \(error)")
      }
    }
  }

[grdsdev]

Hi @EduardMe, thanks for reporting this issue.

I've opened a PR adding a max retry count for the subscribe, set it as 5 but will make it configurable. Also, I need to implement some tests before merging it.

Will also check out how that is handled in the JS (I don't think it is), and then formalize a standard so all the libs have the same behavior.

Thanks, again!

[EduardMe]

Awesome, thanks for this quick response! Have implemented also a retry counter in a fork and so far, so good. When the official release is ready, will switch.

[EduardMe]

Just ran into a main thread deadlock after keeping the app open over night, this time with the retry limit. I'm not sure if this is a bug or we are using it incorrectly. Somehow the subscribe function is called from different threads, ends up on the main thread and in a deadlock.

Maybe it helps to wrap the func into it's own sync thread or so. Will experiment.

Here's the full call graph and threads:
hanging-after-sleep-2.txt

Here is my implementation of the retry counter:

@MainActor
  private func subscribe(retryCount: Int = 0) async {
    if socket.status != .connected {
      if socket.options.connectOnSubscribe != true {
        reportIssue(
          "You can't subscribe to a channel while the realtime client is not connected. Did you forget to call `realtime.connect()`?"
        )
        return
      }
      await socket.connect()
    }

    status = .subscribing
    logger?.debug("Subscribing to channel \(topic)")

    config.presence.enabled = callbackManager.callbacks.contains(where: { $0.isPresence })

    let joinConfig = RealtimeJoinConfig(
      broadcast: config.broadcast,
      presence: config.presence,
      postgresChanges: mutableState.clientChanges,
      isPrivate: config.isPrivate
    )

    let payload = RealtimeJoinPayload(
      config: joinConfig,
      accessToken: await socket._getAccessToken(),
      version: socket.options.headers[.xClientInfo]
    )

    let joinRef = socket.makeRef()
    mutableState.joinRef = joinRef

    logger?.debug("Subscribing to channel with body: \(joinConfig)")

    await push(
      ChannelEvent.join,
      ref: joinRef,
      payload: try! JSONObject(payload)
    )

    do {
      try await withTimeout(interval: socket.options.timeoutInterval) { [self] in
        _ = await statusChange.first { @Sendable in $0 == .subscribed }
      }
    } catch {
      if error is TimeoutError {
        if retryCount < 6 {
          logger?.debug("Subscribe timed out. Retrying in 2 seconds... (attempt \(retryCount + 2) of 6)")
          try? await Task.sleep(nanoseconds: 2_000_000_000) // 2 seconds
          await subscribe(retryCount: retryCount + 1)
        } else {
          logger?.error("Subscribe failed after 3 attempts due to timeout.")
        }
      } else {
        logger?.error("Subscribe failed: \(error)")
      }
    }
  }

[EduardMe]

Attempting to fix the deadlocks with this commit: 0c477ea

Have changed this with Claude Opus:

Summary of Changes

1. AsyncValueSubject.swift: Completely refactored from using LockIsolated to an actor

   • Eliminates manual lock management and potential deadlocks
   • All state access is now async through actor isolation
   • Property renamed from value to currentValue for clarity

2. RealtimeChannel+AsyncAwait.swift: Fixed async function calls

   • Wrapped onPresenceChange and _onPostgresChange calls in Task blocks
   • Necessary because these methods are now async (actor-isolated)

3. RealtimeChannelV2.swift: Made status management async-safe

   • Status property now uses async getter
   • Added @mainactor to critical methods
   • All status checks now use await

4. RealtimeClientV2.swift: Similar async-safety improvements

   • Status property async with proper getter
   • All status comparisons use await
   • State updates wrapped in Tasks

Root Cause

The deadlocks were caused by:

• Lock contention in the previous LockIsolated approach
• Mixed async/sync boundaries accessing shared state
• Race conditions from synchronous status checks

Solution Benefits

• Leverages Swift's actor model for automatic synchronization
• Eliminates entire class of deadlock bugs
• More predictable and maintainable async behavior
• Better Swift concurrency compliance

And the retry commit, if needed: 673dfef

[grdsdev]

Hi @EduardMe thanks for those insights.

I was thinking of refactoring Realtime to use a global actor @RealtimeActor, I've pushed my testing to the realtime-actor branch.

Would you mind give that branch a try? It has some breaking changes tho.

[EduardMe]

Hi @grdsdev, thanks! Have integrated it for testing. Give me a day to see if anything comes up over night.

It doesn't contain the retry limit?

[grdsdev]

Sorry, I think I missed the retry commit, will push it to the branch.

[grdsdev]

@EduardMe just pushed the retry to the branch.

[EduardMe]

Thanks, got it!