Telemetry for 1.1.62: call-audio failures and reconnects, permission prompt, warmup, crash builds

[claude]

Requested by Justin · project thread

Before: when the new Core Audio tap couldn't start or reconnect, PostHog and Sentry only said "system_stream_unavailable". Nothing counted sleep/wake reconnects or AirPods format rebuilds. Nothing recorded how people answer the "can't hear the other side of the call" prompt, or whether models were ready at launch. Crash reports could only be matched by version number.

After: every meeting event says which tap step failed and with what code, how many times call audio reconnected and why, and why it ended if it did. Meeting starts say whether the models were already warm and whether mic-only was the user's choice. The permission prompt reports what people picked and what macOS says afterwards. Dictation reports how fast it started and whether it's the first dictation since launch. Launch reports once when the models are warm. Crashes carry build_revision and build_channel.

Why

So we can tell after 1.1.62 ships whether the new capture, sleep, prompt and warmup pieces work for real users.

Product Impact

• Affects: dictation / meetings
• Lane: meeting reliability / dictation reliability
• Why this matters: the tap path (Use audio-only system capture and add Meetings plus menu #1747) has no fallback, so these codes and counts are the only way to fix it from the field.

What changed

This branch is stacked. It merges the in-scope 1.1.62 heads (#1767 2529424 including #1771 86fa3df, #1768 1aec18d, #1773 b51ff88) so the tracking can hook into their code. Merge it last. #1774 was merged earlier and then backed out in 311a96e after Justin left it out of 1.1.62.

• Tap failures (Use audio-only system capture and add Meetings plus menu #1747): SystemAudioTapFailure → system_tap_step / system_tap_status (e.g. aggregate_creation / neg10877).

• Tap upkeep (Keep meeting system audio alive across repeated sleep/wake and output changes #1762/Keep AirPods clean after wake, handle Mac sleep quietly, and keep call audio through a rate change #1771): SystemAudioTapDiagnostics counts:

  • wake, stall, format and silent-after-wake reconnects
  • rebuild retries, sleeps, and silent-unresolved
  • system_end_reason

  These are bucketed on meeting events and sent as bucketed Sentry tags.

• AirPods meeting start (Start meetings on AirPods without crashing or failing when they switch to call mode #1767): mic_format_rebuilds_bucket.

• Permission prompt (Ask before a mic-only meeting; read system audio permission from macOS #1768):

  • New event meeting_system_audio_prompt_answered (outcome, tcc_status, tcc_status_after, trigger).
  • meeting_recording_started adds mic_only_by_choice and system_permission_check.

• Warmup (Warm models at launch; dictation and meetings never wait on them #1773): new launch_models_warmed (once per launch). meeting_recording_started adds models_warm.

• Dictation: dictation_started adds start_latency_bucket. Both start events add first_since_launch.

• Crashes: SentryPayloadSanitizer.crashRuntimeTagKeys adds build_revision and build_channel.

Left out on purpose:

• A Keep the mic's last words when a recording stops #1770 tail counter, which would add work on the real-time mic path.
• A new mic_route_not_ready classifier value, because the message is shared with existing failures and classifier values must stay stable.

How

• All tap counters live on the tap's own queue and are read through serialized {}. Nothing touches the IOProc.
• A fresh capture object backs each recording, and start() resets the counts.
• The mic rebuild count uses the existing device-switch lock and resets with it.
• Status codes are written neg10877 because the shared category check rejects a leading dash.

How I checked it

• scripts/dev/agent-preflight.sh
• python3 scripts/dev/check-analytics-emitters.py, python3 scripts/ops/normalize-analytics-taxonomy.py --check
• Every new key checked against the substring stripper fragments
• [Held for next release] Dictation: Mac mic first with AirPods, switch mics instead of failing #1774 back-out: its Speech files match Warm models at launch; dictation and meetings never wait on them #1773's head exactly, and its other files match main
• bash build.sh --no-open, bash run-tests.sh, swift test, bash run-integration-smoke.sh: no Swift toolchain in session, so CI is the compile check

Risk Review

• Privacy: fixed step names, numeric OSStatus codes, fixed end reasons, permission states, count buckets and booleans. No device names, paths or error text. Guarded by SentryEventPolicyTests and AnalyticsEventPolicyTests.
• No storage or release-flow change

🤖 Generated with Claude Code

https://claude.ai/code/session_01SRK9LR6bS7HMphU19DMDfy

---

Generated by Claude Code

[claude]

spm-tests on 2527acb is red, but the cause isn't a test failure. XCTest's stall detector aborted the run (signal 6) inside CoreAudioSystemAudioCaptureTests.testAttemptFinishSubscriberCanCancelAcrossBackendQueueWithoutDeadlock, about 20s into its 3s wait. Every suite that sorts after it was skipped. The build was clean, and all 221 tests that ran passed.

I don't think this PR causes it:

• The same test stalled the same way at 18:16Z on Release Transcripted 1.1.62: version, appcast and cask #1756 (head d730471, which is main plus Info.plist), before any of this PR's code existed.
• This PR's changes on that path only set plain vars that are already on the capture queue, such as tapDiagnostics.endReason in fail(). No lock or queue.sync was added. serialized {} is re-entrant, and the IOProc isn't touched.

No fix for this stall exists yet, and the root cause isn't established. This session can't re-run jobs (the API returns 403), so a maintainer re-run of spm-tests is the next step. I'll keep watching the PR.

---

Generated by Claude Code