Uh oh!
There was an error while loading. Please reload this page.
fix(plugin-calendar): gate ObjectCalendar's standalone query on the object schema - #6484
Merged
Merged
Conversation
…bject schema
The fetch effect built its expand set from `objectSchemaRef.current`, a ref
assigned in the render body, and deliberately omitted `objectSchema` from its
dependency list. That bought one effect run per mount and paid for it with the
expansion, permanently: on that one run the ref was still null,
`buildExpandFields` saw no fields, and the query went out with no `$expand` at
all — and nothing re-ran the effect when the schema landed.
Only the standalone `object-calendar` with `dataConfig.provider === 'object'`
reaches this path; one hosted by ObjectView or ListView takes its rows from the
parent, which objectui#6419 already covers. On the standalone calendar every
lookup / master_detail / user / tree field rendered from its raw foreign-key id.
The ref is replaced by a settled-and-keyed resolution (`{ key, def } | null`)
that GATES the record query — the third member of the family after objectui#6271
(ObjectKanban) and objectui#6419 (ObjectView), written as a third copy rather
than an extraction because neither of those landed a shared helper and this
component's key and gate scope both diverge from theirs.
Measured on this component, not inherited. Instrumented adapter, rows tagged
with the query that produced them, observations read from the DOM and from real
child commits, three latency profiles:
before 1 find, `$expand` NEVER present. Raw ids paint and stay.
`objectSchema` 2 finds. Schema slower: raw ids at 30ms, back to the
in the deps "Loading calendar..." placeholder at 71ms, expanded at
94ms — a three-step paint. Schema faster: the first
response is discarded on arrival.
gated 1 find carrying `$expand` the first time, in all three
profiles; one paint, expanded, at 107/88/78ms vs
108/94/79ms via the deps.
The gate is on the read having SETTLED, never on a truthy schema: an adapter
with no `getObjectSchema` and a read that throws both settle with nothing and
the calendar still queries, unexpanded. The gate is scoped to the `object`
provider because an inline `value` set issues no metadata read at all — a
whole-effect gate would hold its query open on a resolution nothing produces.
No public surface change: no `index.ts` touched, no export added or removed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011SfZeFWrhGLHmfq61xbz4q…inate Reverse verification against the branch's base commit turned SIX of the nine pins red, not four: the REJECTS pin discriminates too, through its ordering assertion (`['find', 'schema:issued']` against the base — the query went out before the schema was even requested). The docstring claimed it could not. Corrected to the measured result, and the three pins that genuinely stay green in both directions are now named with the reason each still earns its place. 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
|
os-support-ai
marked this pull request as ready for review
August 26, 2026 04:26
Uh oh!
There was an error while loading. Please reload this page.
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
2 participants
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#6453
ObjectCalendar's fetch effect built its expand set fromobjectSchemaRef.current, a ref assigned in the render body, and deliberately omittedobjectSchemafrom its dependency list. That bought exactly one effect run per mount and paid for it with the expansion, permanently: on that one run the ref was stillnull,buildExpandFieldssaw no fields, the query went out with no$expandat all, and nothing re-ran the effect when the schema landed.Only the standalone
object-calendarwithdataConfig.provider === 'object'reaches this path — one hosted byObjectVieworListViewreceives its rows asdata, which #6419 already covers. On the standalone calendar everylookup/master_detail/user/treefield rendered from its raw foreign-key id.Measured on this component, not inherited
The card was explicit that it was read-from-source, and triage required an instrumented measurement of this effect's dependency set before adopting a shape. Instrumented adapter, rows tagged with the query that produced them, every observation read from the DOM or from a real child commit, three latency profiles:
$expandorigin/mainobjectSchemain the depsLoading calendar...at 71ms → expanded at 94ms (three-step). equal: raw commits but coalesces — a coin flip. schema faster: first response discarded on arrivalThe correct rows land at the same wall clock either way, with half the queries and nothing wrong painted in between. The three-step paint is this component's own finding and is where it parts company with #6419:
loadingis an early return that replaces the whole grid, and the re-run callssetLoading(true), so the calendar does not merely swap ids for names — it drops back to its placeholder first.The gate is on SETTLED, never on a truthy schema
One
{ key, def } | nullstate. Readiness is derived during render asschemaResolution !== null && schemaResolution.key === schemaKey, so switching objects closes the gate in the same commit that changes it and no query can carry the previous object's expand set. Every exit of the resolution effect settles — success, failure, and "there is nothing to read from" alike — so an adapter with nogetObjectSchema, and a read that throws, still query (unexpanded) instead of waiting forever.Two things diverge from #6271/#6419 and are deliberate:
dataConfig.object ?? schema.objectName, notschema.objectName— an authoreddatablock can name a different object than the schema's, and the key must be the object the query will use.objectprovider branch rather than the whole effect. An inlinevaluedata set issues no metadata read (it did not before, and must not now), so a whole-effect gate would hold its render open on a resolution nothing was going to produce. Theinline valuetest is the pin for that.Third hand copy, not an extraction — declared, not slipped in
Triage's family note said to prefer adopting a shared helper if #6419's landed shape extracted one. It did not (
e929c562atouched onlyObjectView.tsx, one test and a changeset), so there was no helper to adopt and the judgement was mine. I read what the existing copies actually share before deciding: the resolution half is genuinely common, but the gate half is not (see the two divergences above), and a helper would have to be a new export on the published@object-ui/react— a permanent public-surface widening — while refactoring two already-landed fixes inside a bug PR. So: third copy, and the convergence question filed as its own card (#6482) with the divergence evidence rather than answered by accretion.Clause ②, stated explicitly: no public surface change. No
**/src/index.tsis in this diff, and noexportline is added or removed (git diff -U0 … | grep -E '^[+-].*\bexport\b'is empty).ObjectCalendar's props are untouched; the change is entirely component-internal state.Tests — 9 pins, and what each one is worth
Reverse-verified by restoring
ObjectCalendar.tsxto this branch's pinned baseb0236259e(never the moving nameorigin/main). Predicted before the run: 6 red, 3 green. Observed: 6 red, 3 green — the same six.Red against the base:
issues ONE query, and it carries the object's $expand—expected [] to have a length of 1sends exactly the schema's expandable fields— sameissues that query only AFTER the schema read settles—expected [ 'find', 'schema:issued' ] to deeply equal [ 'schema:issued', 'schema:settled', 'find' ]paints ONCE, and what it paints is the expanded rows—expected 'Site visit|raw' to be 'Site visit|expanded'(the defect in one line)still queries — and paints — when the schema read REJECTS— red through its ordering assertionre-gates when the object changes— the base sendsvisit's expand set againstnoteGreen in both directions, and why each still earns its place:
adapter exposes NO getObjectSchema— cannot discriminate against the base, which has no gate and queries here anyway. It guards a future wrong shape: it goes red the moment anyone simplifies the gate toif (!objectSchema) return;. Stated as such in the file.inline value data setandhosted calendar takes rows from the parent— controls proving this change turned neither composition into a fetching one.Ghost-assertion guards, since a query count also passes if the view stops fetching: every count is reached only after waiting for a real call; the first test's
waitFortargets the expanded call specifically, so zero fetches times out rather than reading as success;$expandis asserted against the fixture's expandable fields derived through core's ownEXPANDABLE_FIELD_TYPES, in both directions (expandable present, plain absent); and rows are asserted to actually reachCalendarView.Mutation and restore were both proven on disk by blob hash rather than by an exit code —
git hash-objectof the worktree file compared togit rev-parse <ref>:<path>, plus an emptygit diff HEAD, under anEXIT/INT/TERMtrap holding absolute paths.Verification
All on the final commit
6b1f48ba0:pnpm exec vitest run packages/plugin-calendar/→Test Files 14 passed (14)/Tests 101 passed (101)pnpm --filter '@object-ui/plugin-calendar' run type-check→ exit 0 (tsc --noEmit && tsc -p tsconfig.test.json; script name echoed, so not a zero-match pass). The new pin file is confirmed in the program —tsc -p tsconfig.test.json --listFileshits it once.pnpm --filter '@object-ui/plugin-calendar^...' build→ exit 0, run before any judgement so no staledist/could lie.node scripts/check-changeset-presence.mjs→✅ 2 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)node scripts/check-changeset-no-major.mjs→✅ No changeset declares a 'major' bump.Lint is narrowed, and the narrowing is measured (the repo-wide
eslint .does not fit this container's ~10-minute foreground cap alongside the shared verify-lock queue; CI runs the farm regardless):ESLint#isPathIgnoredrather than from a guess about which files count: 3808 of 3809 tracked lintable-extension files are selected.--format jsonoutput: 22 — the wholepackages/plugin-calendarpackage, a superset of my 2 changed files. 0 errors, 118 warnings, of which my two files carry 0 errors (67w onObjectCalendar.tsxunder--no-inline-config, 14w on the test).parserOptions.project,parserOptions.projectServiceandEXPERIMENTAL_useProjectServiceall resolve tonullfor this file, so type-aware linting is not enabled. Every rule verdict in this config is file-local, and a 2-file diff cannot move the verdict on any of the 3786 files outside the narrowing.Out-of-scope findings, filed rather than folded in
$expand#6481 (Bug) —ObjectTree's schema-settled latch is a bare boolean, never keyed by object, so a query after an object switch carries the previous object's$expand. Same family, keying half rather than missing-gate half.$expandgate is now four hand copies, and four more views resolve the schema without gating on it #6482 (finding) — the gate is now four hand copies, and four more views resolve the schema without gating on it. Carries the convergence question and the divergence evidence behind this PR's third-copy decision.Draft, no auto-merge — the PM lands this.
Generated by Claude Code
Generated by Claude Code