Regression: infinite LazyVStack layout cycle hangs app on 1.3.0-beta.806 (same signature as #775)

[deniskern]

Description

The app hangs again with an infinite SwiftUI layout cycle in LazySubviewPlacements — same signature as #775, which was fixed in #806. It reoccurs on 1.3.0-beta.806, which already contains that fix, so this looks like a regression — possibly reintroduced with the new sidebar layout (#828, merged 2026-06-27; my hangs started 2026-07-02).

Main thread is unresponsive for 130+ seconds at 100% CPU until macOS marks the app as Not Responding and I have to force quit. Happening daily.

Environment

• Muxy 1.3.0-beta.806 (806)
• macOS 26.5 (25F71), Apple Silicon (Mac17,9, 48 GB)

Evidence

• 4 .hang reports (3× 2026-07-02, 1× 2026-07-03) in /Library/Logs/DiagnosticReports/
• 2 cpu_resource.diag reports: "90 seconds cpu time over 90 seconds (100% cpu average), exceeding limit of 50% cpu"
• Latest hang: Duration: 133.12s, all 11 samples in the same stack
• Every session for weeks ends with PREVIOUS SESSION ENDED UNCLEANLY in diagnostics.log

Heaviest main-thread stack (trimmed to the distinctive frames)

GraphHost.flushTransactions()
specialized GraphHost.runTransaction(_:do:id:)
AG::Subgraph::update(unsigned int)
AG::Graph::UpdateStack::update()
specialized LazySubviewPlacements.updateValue()
LazyLayoutViewCache.commitPlacedSubviews(from:to:wasCancelled:context:containingSize:)
_LazyLayoutViewCache.initialPlacement(newIndex:newPlacedSubviews:oldPlacedSubviews:wasInsertedToSubviews:context:)
_LazyLayoutViewCache.withPlacementData<A>(_:)
closure #1 in _LazyLayoutViewCache.finalPlacement(...)
protocol witness for LazyLayout.finalPlacement(...) in conformance LazyVStackLayout
protocol witness for LazyLayout.initialPlacement(...) in conformance LazyVStackLayout
specialized LazyStack<>.initialPlacement(...)
Array<A>.motionVectors(closestTo:in:avoiding:distance:)
AGGraphGetValue
AG::Graph::index_of_input_slow(AG::Node&, AG::InputEdge::Comparator)

Same LazySubviewPlacements placement churn as in #775. App binary frames are stripped in the report, so I can't name the exact view.

Session state at hang

• 22 projects, ~52 tabs, ~46 panes, 2-3 windows
• Footprint typically 250 MB - 2.1 GB depending on session age
• Not reliably reproducible; tends to hit after the app has been running for hours with a large session (same as App freezes due to infinite SwiftUI layout cycle in LazySubviewPlacements (114% CPU, 1.7 GB RAM) #775)

Possible lead

#806 fixed conditional children inside LazyVStack ForEach (old Sidebar + omnibox). The new layouts from #828 add fresh LazyVStack usages: TabFocusedSidebar has a conditional child (if !expansionStore.focusMode { TabFocusedAddProjectRow }) plus variable-height expandable project rows, while ProjectFocusedSidebar kept the overlay-based fix pattern. Might be the same class of bug in the new code paths — unverified hypothesis.

Happy to share the full .hang reports (7-10 MB each) if useful.

[saeedvaziry]

@deniskern I can attempt to fix it by I am not able to reproduce this. So if you can reproduce, Please drop a PR and test it yourself