swift: run tailscale_up off the TailscaleNode actor

[prakashrj]

Revised twice. The first version of this PR diagnosed the hang as SOCKS5 proxy routing and quoted a "before" figure I had not actually run — both wrong. The second fixed the diagnosis but worked around the stall with a nonisolated memoized read. This version takes @barnstar's suggestion instead, which is a better fix, and the measurements below say why.

Symptom

LocalAPIClient is unusable during node bring-up. startLoginInteractive(), backendStatus() and watchIPNBus() all block until up() completes — minutes for an interactive login, indefinitely if the user never finishes it. startLoginInteractive() is precisely the call you want in that window.

After up() returns, every one of these works normally. That is why the failure is easy to misread: measured from the healthy state, nothing is wrong.

Cause

up() ran tailscale_up inline on the TailscaleNode actor. That C call blocks until the node is usable, so the actor was held for the whole login and every other actor-isolated call queued behind it.

That is broader than LocalAPIClient. It also means:

• statusJSON() (added in 8077131) is unreachable during login, for the same reason.
• close() is unreachable during login — so the cancellation path tailscale.h documents ("To cancel an in-progress call to tailscale_up, use tailscale_close") could not be used from TailscaleKit at all.

Fix

let res = await Task.detached { tailscale_up(tailscale) }.value

The await suspends up() and releases the actor, so concurrent calls are serviced. TailscaleHandle is Int32, so the capture is trivially Sendable. One line of behaviour change, plus a regression test.

Measurements

Same machine, same session, same test, baseline first. macOS arm64, Xcode 26.1.1, Swift 6.2.1. The node points at a control URL that never completes registration, so it stays in NeedsLogin and up() is genuinely in flight for the whole measurement — the state the defect lives in.

Build	loopback() called while up() is in flight
stock (main)	HUNG — no return within 10007 ms
this PR	returned in 22 ms, addr 127.0.0.1:52042

Both runs assert that up() had not returned, before and after, so neither samples the healthy state.

Why releasing the actor is sufficient on its own. The Go layer never serialised these: tsnet.Server.Up() blocks on an IPN bus watcher rather than a lock, and Loopback() only takes the brief servers map lock. Measured directly against tsnet with testcontrol{RequireAuth: true}, so Up() was stuck in NeedsLogin:

MEASURED: Up() still blocked after 3.001599667s
MEASURED: Loopback() returned in 433.584µs addr=127.0.0.1:51590 proxyCredLen=32 localCredLen=32
MEASURED: Up() confirmed still blocked at end of measurement

This is what makes your suggestion strictly better than the nonisolated memoized read I had proposed. That version only worked when the loopback config had already been resolved before up() was called, and it needed a caveat telling callers to do so. Freeing the actor needs no such caveat: the first loopback() call of a node's life now succeeds during login.

Notes

• loopback() stays actor-isolated on purpose. tsnet's Loopback() lazily initialises s.loopbackListener with no mutex, so the actor's serialisation is load-bearing for concurrent Swift callers.
• Task.detached parks a cooperative-pool thread for the duration of the login. That is the tradeoff of a blocking C call; if you would rather not hold a pool thread for minutes, the same effect is available via a withCheckedContinuation over a dedicated DispatchQueue. Happy to switch — I went with your version as written.
• The full existing suite (testV4, testV6, testProxy, testStatus) passes with this change.

Tracking issue: tailscale/tailscale#20997
Related: #57, from the same work.

[prakashrj]

Correction — I got the diagnosis wrong, and one number in the original table was not measured.

The first version of this PR claimed the hang was caused by proxyVia() routing LocalAPI requests through the SOCKS5 proxy at the loopback address the proxy is itself bound to, and showed:

before (stock) LocalAPIClient.backendStatus() → never returns (>20s cap)

That "before" figure was never measured. I added the probe after applying my patch, so its first run was against the patched build; the stock row was carried over from a downstream note rather than produced by me. Presenting it in a measurement table was my error.

When I did measure stock, it returned 200 OK in 8 ms — the proxy-routing theory was wrong, and proxying a loopback request through its own proxy works fine.

What is actually true, from a run with the node left in NeedsLogin so up() blocked for ~53 s, probing concurrently with up():

Arm	Touches the node actor?	Result during up()
direct HTTP GET /localapi/v0/status, loopback config captured before up()	no	200 OK in 32 ms, BackendState=NeedsLogin
LocalAPIClient.backendStatus() — stock	yes, await node.loopback()	hung, resolved only when up() returned
LocalAPIClient.backendStatus() — patched	no (memoized read)	200 OK in 2 ms

So the real cause is that up() is a blocking C call holding the TailscaleNode actor, while every LocalAPIClient request awaits an actor-isolated accessor for a value that is already memoized and immutable.

The PR has been force-pushed with the correct fix and the body rewritten. The earlier commit is gone from the branch; this comment is the record of what it claimed.

Apologies for the noise — I should have measured the baseline before asserting it.

[barnstar]

The proper fix is probably:

let res = await Task.detached {
      return tailscale_up(tailscale)
}.value

The await should yield there and free up the actors context so you can concurrent fetch the loopback config.

[prakashrj]

Adopted — thank you, this is the better fix and the measurements back it.

I had assumed the actor hop was the only thing I could safely change, so I worked around it by making the memoized read nonisolated. That only helps when the loopback config was already resolved before up(), which is why the PR carried a caveat telling callers to resolve it first. Your version removes the caveat: the first loopback() of a node's life now succeeds during login.

Measured before and after, same machine and session, node held in NeedsLogin so up() is genuinely in flight:

build	loopback() during in-flight up()
stock	HUNG — no return within 10007 ms
await Task.detached { tailscale_up(tailscale) }.value	returned in 22 ms

I also checked that the Go side can actually serve the call rather than just accepting it — Up() blocks on the IPN bus watcher, not a lock, and against tsnet directly with testcontrol{RequireAuth: true}, Loopback() returned in 433 µs while Up() was still blocked. So releasing the actor is sufficient on its own.

Two things it fixes beyond LocalAPIClient: statusJSON() was stalled for the same reason, and so was close() — which meant the cancellation path tailscale.h documents ("to cancel an in-progress tailscale_up, use tailscale_close") could not be reached from TailscaleKit.

Two notes:

• I kept loopback() actor-isolated. tsnet's Loopback() lazily initialises s.loopbackListener with no mutex, so the actor's serialisation is doing real work for concurrent Swift callers.
• Task.detached parks a cooperative-pool thread for the length of the login. I went with your version as written; if you would rather not hold a pool thread for minutes, the same effect is available via a withCheckedContinuation over a dedicated DispatchQueue. Say the word and I will switch it.

Added a regression test that measures in the blocked state, since measured after up() returns this defect is invisible. Full suite green.