Uh oh!
There was an error while loading. Please reload this page.
test(plugin-map): point the reach test narration at where the 'Marker' placeholder actually lives - #6341
Merged
os-support-ai merged 1 commit intoAug 25, 2026
Conversation
…' placeholder actually lives The comment above the discriminating `titleField` arm in `ObjectMap.listViewMapConfigReach.test.tsx` said `'Marker'` was "the literal `getMapConfig` falls back to". It never lived there. `getMapConfig` starts at `ObjectMap.tsx:345`; the placeholder is `getRecordDisplayName`'s `fallback` option in the marker-building transform some 400 lines away, and since objectui#5953 `getMapConfig` forges no title binding on any branch. The historical half was also merged with a different branch's symptom. Measured at the parent of the forward commit (e2e8e68^): the read site was `mapConfig.titleField ? record[mapConfig.titleField] : 'Marker'`, and `getMapConfig`'s flat branch carried `titleField: schema.titleField || 'name'`. Pre-forward `ListView` always emitted `locationField: 'location'`, so this arm took that flat branch, got a forged `'name'`, and — these fixture records carry no `name` key — read `undefined`, not `'Marker'`. Also drops the now-stale "the marker transform reads `record[titleField]`": the transform resolves through `getRecordDisplayName`, which checks `options.titleField` at step 0, so the declared binding still wins outright and the arm still pins a real read rather than a forwarded prop. Comment only. No assertion, fixture or expected value changed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011SfZeFWrhGLHmfq61xbz4q
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
This was referenced Aug 25, 2026
os-support-ai
marked this pull request as ready for review
August 25, 2026 14:36
Uh oh!
There was an error while loading. Please reload this page.
os-support-ai
deleted the
claude/issue-5977-mapconfig-reach-stale-narration
branch
August 25, 2026 14:47
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes#5977
Comment-only change to one test file. Head
4cb788f4e.1. Dispatch premise table
Every coordinate re-derived against
origin/main@79ebf30d1(the dispatch order and the claim comment were written againstc38162d7c;mainmoved between them).packages/plugin-map/src/ObjectMap.listViewMapConfigReach.test.tsx, directly undersrc/, notsrc/__tests__/ls packages/plugin-map/src/— the file is a direct child;plugin-maphas nosrc/__tests__/:136-141, not exactly:138:136-140;:141is thefireEvent.clickit precedesgetMapConfigis defined atObjectMap.tsx:345function getMapConfig(schema: MapConfigSource): ObjectMapConfig {at:345fallback: 'Marker'is atObjectMap.tsx:771, outsidegetMapConfig:771, inside the marker-buildinguseMemothat begins at:735—getMapConfigends at:415The claim comment's corrected framing — misattributed, not deleted — holds. The
'Marker'literal is alive at:771; what the narration got wrong is whose literal it is.2. What I established the two functions actually do
getMapConfig(ObjectMap.tsx:345-415) has three return paths, and none of them now forges a title binding:mapblock wins outright —return { ...config, style: config.style || style }, sotitleFieldis exactly what the author wrote and nothing more;titleField: schema.titleFieldwith an in-code note readingNo || 'name' (objectui#5953);descriptionFieldonly, withDeliberately NO titleField (objectui#5953).The marker path (
ObjectMap.tsx:735-800) no longer does a bare property read. At:769:'Marker'is therefore an option handed to the resolver, not agetMapConfigliteral. Inpackages/core/src/utils/record-title.tsthe resolver checksoptions.titleFieldat step 0 (valueAt(record, options?.titleField) ?? valueAt(record, objectDef?.titleField)), so a declared binding still wins outright;options.fallbackis only reached at the very floor —Record #<id>handles any record that has an id, so'Marker'now surfaces only for a truly id-less record.The historical half — measured, and it needed correcting too
The dispatch asked me to determine whether the history was still accurate. It was not, and this is exactly the merge the card body called out.
The forward is
e2e8e68f1(feat(plugin-list): read the spec's view-levelmapblock on list views). At its parent:ObjectMap.tsx:668ate2e8e68f1^):const title = mapConfig.titleField ? record[mapConfig.titleField] : 'Marker';— so'Marker'was the else-arm of the read site's ternary, reachable only when no binding existed;getMapConfig's flat branch (:375) carriedtitleField: schema.titleField || 'name', and its default branch (:395) carriedtitleField: 'name'.'name', never'Marker', is whatgetMapConfigfell back to.For this arm specifically: pre-forward
ListView'scase 'map'readschema.options?.maponly and always emittedlocationField: schema.options?.map?.locationField || 'location'. This test declaresmapat the schema root, so the block was dropped,locationField: 'location'still arrived,getMapConfigtook the flat branch, andtitleFieldcame out as the forged'name'. The fixture records are{ id, title, blurb, location }— nonamekey. So the pre-forward title wasundefined, not'Marker'.The old comment asserted the
'Marker'symptom and theundefinedsymptom as one thing. They are two branches with two visibly different outcomes.3. The narration, before and after
Before (
:136-140):After (
:136-146):The reason the discriminating arm exists is kept — the arm still pins that the title is a real read of the declared binding rather than a forwarded prop, and the pre-forward symptom is still narrated. Only the pointer and the symptom's identity changed.
4. Verification — and what is structurally blind here
The test suite cannot verify this change, and that is expected. Comments do not execute: the 92 assertions in
packages/plugin-mapproduce byte-identical results before and after, by construction. A green run is evidence the change is inert, not evidence the new prose is true. Type-check is blind for the same reason one level down — TypeScript strips comments, so the file parses identically either way; it only proves I did not break the comment syntax. Lint, control-byte andvi.mockscans read the changed bytes but judge form, never claims. Changeset presence judges declaration, not content.The actual verification is the code reading in §2 —
getMapConfig's three branches atObjectMap.tsx:345-415, the resolver call at:769-772,getRecordDisplayName's step ordering inpackages/core/src/utils/record-title.ts, andgit show e2e8e68f1^for the pre-forward read site, flat branch andListViewmap case. Every sentence in the new comment traces to one of those.Gate table
Gate set derived from the job step lists under
.github/workflows/. Exit codes captured before any pipe; verdict lines are each gate's own output.changeset-presence.yml)node scripts/check-changeset-presence.mjs✅ 1 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s) … Every one of them has an EMPTY frontmatter — declared as releasing nothing, which is the explicit exemption and a complete answer to this gate.changeset-guard.yml)node scripts/check-changeset-no-major.mjs✅ No changeset declares a `major` bump.control-bytes.yml)node scripts/check-control-bytes.mjs✅ check-control-bytes: OK (scanned 5225 tracked text file(s); skipped 85 binary).vi-mock-specifiers.yml)node scripts/check-vi-mock-specifiers.mjs✅ check-vi-mock-specifiers: OK (3748 tracked source file(s), 2060 test-named; 439 carry a mock; 684 relative specifier(s) resolved …)shell-escape-residue.yml)node scripts/check-shell-escape-residue.mjs✅ check-shell-escape-residue: OK (4/4 root(s) resolved … 0 occurrence(s) outside a fence)ci.yml)pnpm --filter @object-ui/plugin-map run type-check> @object-ui/plugin-map@17.6.0 type-check→> tsc --noEmit && tsc -p tsconfig.test.json, no diagnosticsci.yml)pnpm exec vitest run --maxWorkers=2 packages/plugin-map/Test Files 16 passed (16)·Tests 92 passed (92)lint.yml)pnpm --filter @object-ui/plugin-map run lint✖ 126 problems (0 errors, 126 warnings)— all pre-existing; the three in this file areno-explicit-anyat:47/:50/:54, far above the editSupporting evidence, since "green" is cheap and the ways to fake it are not:
tsc -p tsconfig.test.json --listFileslistsObjectMap.listViewMapConfigReach.test.tsx(1 hit), so the edited file really is in that program;packages/plugin-map/srccontains exactly 16 test files and vitest reported16 passed (16);4cb788f4e, andgit status --porcelainplusgit diff HEAD --statare both empty, so the heavy runs above measured exactly this commit's tree;pnpm --filter @object-ui/plugin-map exec vitest run, which the repo's own guard refused (vitest 调用被拒绝:从包目录跑 vitest 会静默跑错测试集, objectui#3378). That exit 1 is a refused invocation, not a red gate; it is superseded by the repo-root form in the table, which is what CI runs.Declared narrowing: I ran the package-scoped equivalents (
--filter @object-ui/plugin-map) rather than the repo-widepnpm test/pnpm type-check/pnpm lintthat CI runs across every package. The diff is one comment block in one package plus one changeset; CI runs the full farm on this PR regardless.5. The changeset, and a correction about
skip-changesetTriage suggested the
skip-changesetlabel. That label is a phantom in this repository — it exists as a label object but nothing reads it.scripts/__tests__/ci-cd-pipeline-doc.test.tspins this deliberately:Confirmed independently: neither
.github/workflows/changeset-presence.ymlnorscripts/check-changeset-presence.mjsmentions it. So I followed the gate's own verdict line instead and declared the change with an empty-frontmatter changeset (.changeset/plugin-map-reach-test-narration.md) — the route the gate names as "a complete answer". No label was applied or minted. Nomajoranywhere;content/docs/releases/untouched.6. Out-of-scope finding — reported, not fixed
Per the dispatch, the sweep was not widened. Of the other files narrating
getMapConfig,ListView.tsx,ListView.mapViewLevelConfig.test.tsx,ObjectMap.markerTitle.test.tsxandInterfaceListPage.mapConfig.test.tsxare all clean — they either discuss precedence (objectui#5018) or already speak of'name'in the past tense.CHANGELOG.mdwas not touched.One file does carry the same defect class, and it is more than prose —
packages/app-shell/src/views/InterfaceListPage.tsx:230-241:All three present-tense claims are false on
maintoday, and the "filed separately" general fix has landed (objectui#5953, PR #5975). The prose is stale, but the live question underneath it is whether the derived title binding at that seam is now redundant — or worse, actively harmful: it lands asoptions.titleField, which the resolver evaluates at step 0, ahead of the object's own declarednameField. That is a behaviour question for triage, not a comment fix. Left entirely untouched for the PM to file.Generated by Claude Code