# BTT 6.773 — synchronous Core Data fetch on the main thread causes system-wide input stalls

## Pre-report checklist
- **Restart tried — does not help.** This Mac was rebooted on 2026-09-06 at 12:10:46.
  BTT diagnostic reports exist both before that reboot (07:12) and after it
  (12:16, 12:49, 16:00), so the problem survives a restart.
- **No crash log is available, because BTT does not crash — it hangs.** The system
  produced 4 `cpu_resource.diag` and 3 `hang` reports for BTT and zero crash reports.
  The `hang` reports attached here are the corresponding artifact.
- **This IS the latest alpha.** The alpha feed declared in the app bundle
  (`SUFeedURLHighSierraAlpha` = `https://updates.folivora.ai/highsierraalpha.xml`) currently
  publishes 6.773 / build 2026090402, dated Fri 04 Sep 2026 — the exact build installed here.
  The release channel (`appcast.xml`) is still on 6.748, so this machine is running ahead of
  the stable channel, on the newest available alpha.

## Environment
- BetterTouchTool **6.773 (2026090402)**
- macOS 26.6.2 (build 25G83), MacBookPro18,4 (M1 Max, 10 cores), 32 GB
- Settings store was migrated from 6.443 during the update

## Symptoms
All of these are **system-wide**, not limited to BTT's own windows:
- Keystrokes stall for roughly 3 seconds immediately after switching applications
- Korean/English input-source switching is delayed by several hundred milliseconds
- Periodic beachballs; typing freezes completely for seconds at a time.
  **A three-finger tap on the trackpad triggers this within seconds, reliably.**
- Quitting BTT makes all three disappear at once. Launching BTT alone, with every other
  input-related app closed (Karabiner, Hammerspoon, Logitech Options+, CheatSheet, RunCat,
  Only Switch), reproduces all three.

## Steps to reproduce
The most reliable trigger on this machine is a **three-finger tap on the built-in trackpad**:

1. Launch BTT with the settings store described below (346 entities / 209 enabled triggers).
2. Let it settle for 30-60 seconds.
3. Three-finger tap the trackpad.
4. Within a few seconds the beachball appears and **all keyboard input stops system-wide**
   for several seconds. The BTT window itself becomes unresponsive.

Switching applications, and switching the macOS input source (Korean <-> English), cause the
same stall in a milder form.

Important: **disabling all 71 gesture triggers does not prevent it.** A three-finger tap still
produces the stall with every gesture trigger turned off, which suggests the cost sits in the
gesture-recognition / notification-driven fetch path rather than in executing a gesture's
assigned action.

BTT's own log around these events (attached logs contain 85 `tiptap` lines and 24
`three finger click block` lines):

```
LMDrag|dragged after three finger click block
tiptap|candidate contact (resting finger down 1.94s)
tiptap|rejected: fingers 0.57 apart (max 0.55)
tiptap|rejected: resting finger moved / palm heuristics (f1 0.00/0.48 f2 0.52/0.24 ...)
```

Relevant trackpad settings on this machine:
```
BTTThreeFingerTipTapMinSpread                     = 0.03
BTTTpThreeFingerSwipeSensitivity                  = 0.3
tpThreeFingerDoubleTapDelay                       = 0.5
BTTAllowThumbIfAllFingersArePlacedSimultaneously  = 1
```
Trackpad: built-in on MacBookPro18,4.

## Onset
The machine updated BTT 6.443 → 6.773 on 2026-09-06 at 06:54. The first BTT diagnostic
report on this machine is from 07:12 the same morning. `/Library/Logs/DiagnosticReports`
retains entries for other processes back to 09-01, and contains **no BTT reports at all
before the update**.

## Kernel evidence
Four `cpu_resource.diag` reports, each hitting the 90-second CPU limit:

| Time  | CPU time / window | Average |
|-------|-------------------|---------|
| 07:12 | 90 s over 176 s   | 51 %    |
| 12:16 | 90 s over 90 s    | 100 %   |
| 12:49 | 90 s over 103 s   | 87 %    |
| 16:00 | 90 s over 140 s   | 64 %    |

All four heaviest stacks bottom out in the same place — a synchronous Core Data fetch
running on the **main thread**:

```
-[NSApplication run]  →  main dispatch queue
  →  __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__     (in 3 of the 4 reports)
    →  BetterTouchTool
      →  -[NSManagedObjectContext executeFetchRequest:error:]
        →  -[NSSQLCore executeRequest:withContext:error:]
          →  -[NSSQLiteConnection performAndWait:]
            →  sqlite3_step  →  sqlite3VdbeExec
```

In the 16:00 report, **22 of 23 samples** are inside that fetch.

The `On Behalf Of` field names the processes whose notifications drove the work:
**iTerm2, KIM_Extension (the macOS Korean input method), and Only Switch**. This lines up
with the input-source symptom — every input-method event appears to trigger a fetch.

BTT's own log shows the corresponding cache work, e.g.:
```
BTTItemTrigger: cache updated - 0 trigger row(s) fetched (fetch error: (null))
```

## Why this stalls the entire system
BTT holds a CGEventTap. While its main thread is blocked inside the fetch, key events
cannot be forwarded, so every application on the machine is affected — which is why the
symptom presents as an OS-level input problem rather than a BTT problem.

## The store is small
The settings store holds **346 entities total (209 enabled triggers)**. A single fetch over
this should take microseconds, and the indexes are intact — 26 indexes on `ZBTTBASEENTITY`,
identical to a store BTT creates from scratch. `PRAGMA integrity_check` returns `ok`.

The cost therefore does not appear to come from any individual query being slow, but from
the fetch being executed **once per incoming notification, synchronously, on the main
thread**, at a rate driven by unrelated processes.

## Ruled out locally
- iCloud sync disabled → still reproduces
- All 71 gesture triggers disabled → still reproduces (so it is not action execution)
- No key-sequence triggers configured (0)
- Clipboard manager holds only 33 clips
- Store integrity `ok`; index set identical to a freshly created store
- Other input-tapping apps quit → symptoms gone; BTT alone → symptoms return

## Attached
- `diagnostic_reports/` — 4 × `cpu_resource.diag`, 3 × `hang`
- `btt_logs/` — BTT's own logs covering the period
