Recurring crash: NSInternalInconsistencyException in NSHostingView constraint update during display cycle

[ebolamerican]

Description

TypeWhisper crashes roughly once a day with an uncaught AppKit exception thrown during the display cycle. The app auto-relaunches, so the crashes are easy to miss — I only noticed after finding a string of near-daily reports in DiagnosticReports (Aug 29, Aug 30, Aug 31 on my machine, and older ones before that).

The signature is identical every time: NSHostingView.didChangeValue(forKey:) → invalidateSafeAreaCornerInsets() → setNeedsUpdate() → -[NSWindow(NSDisplayCycle) _postWindowNeedsUpdateConstraints] throws (constraint update requested at an illegal point in the display cycle), AppKit's _crashOnException: aborts.

Crash backtrace (lastExceptionBacktrace, v1.7.0 build 1161, macOS 26.4.1)

CoreFoundation: __exceptionPreprocess + 164
libobjc.A.dylib: objc_exception_throw + 88
CoreFoundation: +[NSException exceptionWithName:reason:userInfo:] + 0
AppKit: -[NSWindow(NSDisplayCycle) _postWindowNeedsUpdateConstraints] + 1716
AppKit: -[NSView _informContainerThatSubviewsNeedUpdateConstraints] + 64
AppKit: -[NSView setNeedsUpdateConstraints:] + 468
SwiftUI: NSHostingView.setNeedsUpdate() + 176
SwiftUI: NSHostingView.requestUpdate(after:) + 676
SwiftUICore: closure #1 in ViewGraphRootValueUpdater.invalidateProperties(_:mayDeferUpdate:) + 228
SwiftUICore: ViewGraphRootValueUpdater.invalidateProperties(_:mayDeferUpdate:) + 192
SwiftUI: NSHostingView.invalidateSafeAreaCornerInsets() + 208
SwiftUI: NSHostingView.didChangeValue(forKey:) + 328
SwiftUI: @objc NSHostingView.didChangeValue(forKey:) + 68
CoreFoundation: __CFSetApplyFunction_block_invoke + 28
CoreFoundation: CFBasicHashApply + 144
CoreFoundation: CFSetApplyFunction + 228
AppKit: __reusableDependencyContextForKey_block_invoke + 140

The faulting main-thread stack ends in +[NSApplication _crashOnException:] via NSDisplayCycleObserverInvoke → updateConstraintsForSubtreeIfNeeded.

Steps to Reproduce

No reliable trigger identified — it fires in the background during normal operation (timestamps on my reports: 18:59, 18:00, 12:59 local on consecutive days). Happy to attach full .ips files if useful.

macOS Version

macOS 26.4.1

TypeWhisper Version

1.7.0 (1161); identical signature in reports from earlier builds as well.

[ebolamerican]

Two more occurrences (38 seconds apart) with a fuller backtrace that refines the mechanism. The exception is raised while SwiftUI itself animates a window resize from inside the window's layout pass:

NSHostingView.windowDidLayout()
NSHostingView.updateAnimatedWindowSize(_:)
-[NSWindow _setFrameCommon:display:fromServer:]
-[NSView setFrameSize:]
… → NSHostingView.didChangeValue(forKey:) → invalidateSafeAreaInsets()
  → setNeedsUpdate() → -[NSWindow _postWindowNeedsUpdateConstraints]  ← throws
… ← -[NSWindow layoutIfNeeded] ← NSDisplayCycleObserverInvoke

So the re-entrancy isn't (only) app-initiated placement: windowDidLayout fires during layoutIfNeeded inside the display cycle, SwiftUI's updateAnimatedWindowSize synchronously re-frames the window, and the resulting KVO invalidation trips _postWindowNeedsUpdateConstraints. Reliable trigger on my machine: starting a new dictation while the "AI post-processing failed" feedback toast is animating (a state transition that animates the indicator content size). #1233 / its PR removes the deterministic path into that toast; the underlying race presumably remains reachable from any animated content-size change during layout.

[SeoFood]

A new field report shows that this crash family is still reachable in TypeWhisper 1.7.0 (build 1167) on macOS 26.6.2 (25G83), Mac16,8.

Build 1167 corresponds to v1.7.0-daily.20260901 and already includes the safeguards from #1160, #1225, and #1232.

Reported trigger:

1. Open the command palette by double-pressing Command.
2. Select one of the previous dictation entries.
3. TypeWhisper crashes.

Crash timestamp: 2026-09-01 16:06:03 +0200.

The report has the same display-cycle constraint-update signature:

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Triggered by Thread: 0, Dispatch Queue: com.apple.main-thread

AppKit  -[NSWindow(NSDisplayCycle) _postWindowNeedsUpdateConstraints]
AppKit  -[NSView setNeedsUpdateConstraints:]
SwiftUI NSHostingView.setNeedsUpdate()
SwiftUI NSHostingView.requestUpdate(after:)
SwiftUICore ViewGraph.invalidateTransform()
SwiftUI NSHostingView.updateTransform()
SwiftUI NSHostingView.updateWindowContentSizeExtremaIfNecessary()
SwiftUI NSHostingView.updateConstraints()
AppKit  NSDisplayCycleFlush

The reporter was not certain whether it was exactly the same crash as their earlier one, but the build, trigger, and stack show that the underlying display-cycle failure remains reproducible through the previous-dictation palette path.

[ebolamerican]

Root cause for the notch-panel variant of this stack, with a fix pushed to #1232: the NotchIndicatorPanel's NSHostingView sits over the hardware notch, so on macOS 26 AppKit fires _effectiveSafeAreaCornerInsets / _effectiveCornerRadii KVO on it during every frame change; SwiftUI responds with invalidateSafeAreaCornerInsets → setNeedsUpdateConstraints, and when the frame change happens inside NSHostingView.windowDidLayout → updateAnimatedWindowSize the constraint request lands mid-layout and _postWindowNeedsUpdateConstraints throws. hostingView.safeAreaRegions = [] removes that observer entirely (confirmed with a standalone KVO-logging probe). Details and caveats in the #1232 comment.

The palette variant reported above (updateWindowContentSizeExtremaIfNecessary → updateConstraints on the selection palette) is a separate SwiftUI path and is not addressed by that commit.

[ebolamerican]

Retracting my safe-area-regions explanation above — it was not the cause. The exception reason, captured live with lldb: "The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window" on the NotchIndicatorPanel, whose frame had grown to 1460×2990. It's a feedback loop between the panel's own toast-time resize and NSHostingView's WindowSizeBridge animating the window to follow an animated root-size change from inside windowDidLayout. Fix (hosting view at a fixed size inside a container; only the window resizes) is on #1232 with lldb verification details.

[SeoFood]

The notch-panel layout feedback loop is addressed in PR #1285: the SwiftUI hosting view keeps a fixed size, while an AppKit container explicitly centers and top-anchors it as the window resizes. The first-mouse test now checks the actual receiving view.

Validation on commit 4bc7d61: 1,760 local app tests passed, all executed PR checks passed, and the manual feedback-to-recording smoke test passed with centered, fully visible content and no observed crashes or hangs. Long-term recurrence of the original intermittent crash has not yet been evaluated on this build.

Closing via PR #1285 as the fix enters main. It will be available in the next daily build containing this merge; it is not yet shipped in a published release. This addresses the notch-panel path discussed here, not the separate palette or audio-thread crash paths.