Conversation
…ansion resolver (#3338) expandToGeometryBearingIds has one production call site the codebase knows about, cameraCallbacks.resolveHighlightIds, which LensPanel, PropertiesPanel and both SearchModal isolate paths already route through. The SDK/MCP visibility adapter's isolate() (scripts, the viewer_isolate tool) is a fifth channel, not named in #3338: it expands spatial-structure refs but never routed the result through the same resolver, so isolating a geometry-less IfcElementAssembly by ref left an id with no mesh in the isolation set and showed an empty viewport — the same #2532 failure mode, in an unenumerated channel. isolate() now resolves through cameraCallbacks.resolveHighlightIds the same way the other four channels do, falling back to the unresolved ids when no renderer has registered one yet (matching every other channel's fallback).
|
Warning Review limit reached
This review includes 3 billable files and costs up to $0.75. Or wait 14 minutes for your next included review. View limit detailsLimit details: You’ve used all 2 included reviews currently available. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Comment |
Viewer benchmark✅ No threshold regressions detected. 01_Snowdon_Towers_Sample_Structural(1).ifcBaseline recorded 2026-07-01T20:31:05.538Z on github-actions ubuntu-latest, viewer-benchmark-ci (headless Chrome, SwiftShader ANGLE), production build.
AC20-FZK-Haus.ifcBaseline recorded 2026-07-01T20:30:59.972Z on github-actions ubuntu-latest, viewer-benchmark-ci (headless Chrome, SwiftShader ANGLE), production build.
Refresh the baseline from a CI run: dispatch the Benchmark workflow with |
Summary
Refs #3338 ("Assembly drill-down: expansion is one call site every channel must remember to use"). This fixes ONE concrete, verified gap the issue's own enumeration missed; it does not attempt the larger open design question the issue raises (resolver-property vs explicit user action).
What's covered vs what forgets
expandToGeometryBearingIds(apps/viewer/src/utils/aggregation.ts) has one production call site,cameraCallbacks.resolveHighlightIds, defined inViewport.tsx. Channels that route through it:LensPanel.tsx:1403PropertiesPanel.tsx:801SearchModal.text.tsx:139SearchModal.filter.tsx:401A fifth channel, not named in #3338, did not:
apps/viewer/src/sdk/adapters/visibility-adapter.ts'sisolate()— reached by scripts (ifc.isolate(...)) and the MCPviewer_isolatetool. It already expands spatial-structure refs (storey, building) via its ownexpandSpatialRef, but the result never passed throughcameraCallbacks.resolveHighlightIds. Isolating a geometry-lessIfcElementAssemblyby ref therefore isolated an id with no mesh — the same #2532 failure mode (blank viewport), just in a channel the issue's audit didn't enumerate.Fix
isolate()now resolves its assembled global ids throughstate.cameraCallbacks.resolveHighlightIds— the same choke point the other four channels use — falling back to the unresolved ids when no renderer has registered one yet, matching every other channel's own fallback.Root cause
cameraCallbacks.resolveHighlightIdsis an optional callback each channel has to remember to call; a new channel that skips it compiles fine and silently isolates un-expanded ids.This PR closes the one instance of that already found live in the tree. It does not add a structural (compile-time) guarantee against a future sixth channel forgetting — that's the open design question #3338 raises, and is out of scope here.
Test plan
visibility-adapter.assembly.test.tsfails against the pre-fixisolate()(isolates the raw assembly id[42]instead of its parts[9001, 9002])expandToGeometryBearingIds/aggregation.test.tsunaffected (53/53 pass)pnpm typecheck(root, turbo) — 1503/1503 test files in program, 0 errorspnpm lint— 0 errorsnode scripts/check-module-size.mjs— OKnode scripts/check-source-text-assertions.mjs— OK, 0 new@ifc-lite/viewerpatch)🤖 Generated with Claude Code