Contact fetch with extraProperties=avatar blocks the Node event loop ~5s, causing client disconnect/reconnect loops ("connecting")

[johndkos]

Environment

• Server: 1.9.9 (latest stable)
• macOS: 15.7.7 (build 24G720)
• Messages: 14.0
• Private API: enabled, mode process-dylib, helper connected (helper_connected: true)
• ~2,500 contacts, served live from the macOS Contacts framework (the server's own contact DB table is empty)

Summary

GET /api/v1/contact?extraProperties=avatar takes ~4.3–5.7s and blocks the Node event loop for its duration. Clients re-request contacts-with-avatars on every (re)connect; because the block exceeds the client's ~5s reachability-probe window, the client tears down the socket (client namespace disconnect) and reconnects, which re-triggers the fetch. The result is a repeating loop that surfaces on clients as being stuck on "connecting."

Reproduction (measured on the server itself, bypassing any tunnel)

Idle GET /api/v1/ping ≈ 0.002s. Fire GET /api/v1/contact?extraProperties=avatar in the background and ping repeatedly during it:

ping #1 (during avatar fetch): 4.83s
ping #2–9 (after the synchronous phase): ~0.002s each

A single ~5s synchronous block, not a gradual slowdown. For comparison, on the same server:

• GET /api/v1/contact (no avatars): ~6–25ms
• GET /api/v1/server/statistics/totals: ~3ms

Only the avatar variant blocks.

Server log pattern (redacted)

Request to /api/v1/contact (URL Params: {"extraProperties":"avatar"})
Request to /api/v1/contact took 5313 ms
[SocketRoutes] Client <id> disconnected! Reason: client namespace disconnect
Request to /api/v1/contact (URL Params: {"extraProperties":"avatar"})
Request to /api/v1/contact took 5455 ms
[SocketRoutes] Client <id> disconnected! Reason: client namespace disconnect

(repeating every ~15–30s)

Suspected cause

Synchronous avatar loading from the macOS Contacts framework (node-mac-contacts) on the main thread; cost scales with contact count. At ~2,500 contacts the block sits right around the client's ~5s probe timeout, which makes the disconnects intermittent.

Impact

Clients (Windows desktop observed) repeatedly drop to "connecting"; each reconnect re-triggers the blocking fetch.

Possible fixes

• Load avatars off the main thread (worker), or stream/paginate, or cache avatars server-side so the request is a fast read rather than a live Contacts-framework call.
• Is this already addressed by the contacts API work in Contacts API Improvements #701 / the development branch? If so, would a stable release resolve it (cf. macOS 15 Server Update 2.0.0? #700 re: a macOS 15 / 2.0.0 release)?

A fuller redacted server log (last ~3h) is available if helpful.

[johndkos]

Reproduced on localhost with a concurrent-request test — the avatar fetch blocks the event loop ~5s.

Server: macOS 15.7.7, ~2,500 contacts. Hitting the local API directly (no proxy/network in the path):

SRV="http://localhost:1234"; PW="<server-password>"
# fire the avatar contact fetch in the background, ping continuously while it runs
curl -s -o /dev/null -w "AVATAR FETCH: %{time_total}s, %{size_download} bytes\n" \
  "$SRV/api/v1/contact?password=$PW&extraProperties=avatar" &
while kill -0 $! 2>/dev/null; do
  curl -s -o /dev/null -w "ping during fetch: %{time_total}s\n" "$SRV/api/v1/ping?password=$PW"
done

idle ping:          0.0015s
ping during fetch:  4.9588s   <-- blocked
ping during fetch:  0.0048s
AVATAR FETCH:       5.0213s, 33,373,213 bytes  (~33 MB)

A /ping issued the instant the avatar fetch starts is stuck ~5s until it completes, then snaps back to ~2ms — a single-threaded event-loop block. The extraProperties=avatar response is ~33 MB (vs ~1.3 MB without), and that payload appears to be base64-encoded synchronously on the main thread (contactInterface.ts imports byte-base64), stalling pings, new-message pushes, and the desktop client's health probe for the duration.

Client impact: the desktop client issues a contact refresh with extraProperties=avatar on every socket reconnect → each reconnect blocks the server ~5s → health probe times out → socket drops → reconnect → repeat. Still reproduces on the latest 2.0 desktop beta and after halving the contact count, so it's purely server-side.

Possible fixes: offload the base64 off the main thread (worker_thread), or drop full-res avatars from the bulk /contact path and return only contactImageThumbnail (full avatars fetched lazily) — the list view only needs thumbnails. Happy to open a PR if you have a preferred direction.