Repository navigation
REST GET silently omits @computed fields from responses (computed getters are non-enumerable) #1484
Description
Activity
Extending this: the same non-enumerable
@computedgetter root also drops computed fields from change-event subscription payloads across all three transports (SSE, MQTT, WebSocket), not just REST GET.QA repro (harper main f447404 / v5.1.13): a
Usertable withfirstName,lastName, andfullName @computed(...). Subscribe, then mutate:- SSE/WS change-event
valueomitsfullNameon insert, on a source-field PATCH, and on an unrelated-field PATCH (the event fires,fullNameis simply absent — not stale, not recomputed). - MQTT delivers the bare record
{id,firstName,lastName}— also nofullName. - Meanwhile ops
search_by_valueand SQLSELECTreturnfullName:"Pro Be"correctly, proving the value materializes.
So the omission is confined to the two serializers that walk own-enumerable props — REST-GET
JSON.stringifyand the change-event serializer. GraphQL resolves each requested field explicitly, so it already includes computed fields and needs no change.Net: the fix here (make
@computedenumerable by default, or have these serializers explicitly include computed getters) should cover REST GET and the SSE/MQTT/WS subscription payloads in one shot. Most likely to bite reactive-UI / dashboard clients that subscribe expecting derived fields.Repro tests:
qa369-computed-subscription.test.ts(SSE),qa371-computed-sub-transports.test.ts(MQTT+WS).— from Harper exploratory QA (KrAIs)
- SSE/WS change-event
- added a commit that references this issue
on Jul 5, 2026 - added a parent issue
on Jul 7, 2026 - added 4 commits that reference this issue
on Jul 9, 2026 - added 5 commits that reference this issue
on Jul 24, 2026 - added a commit that references this issue
on Aug 28, 2026 - added a commit that references this issue
on Aug 28, 2026
REST GET responses (collection scan and single-record point-read) silently omit
@computedfields, while opssearch_by_value(get_attributes) and SQLSELECT */SELECT computedField/aggregates all return them with correct values.Root:
@computedgetters are installed as non-enumerable properties onstructPrototype—resources/graphql.ts:229only setsenumerable: truewhen the separate@enumerabledirective is applied, so a plain@computedfield defaults to non-enumerable. REST serialization usesJSON.stringify, which walks only own-enumerable properties → the computed getter is invisible. The ops path iterates theattributes[]array explicitly, so it always includes computed fields.Workaround (predicted): annotate the computed field with
@enumerable.Fix: make
@computedfields enumerable by default (or have the REST serializer include computed getters explicitly) so REST GET matches ops/SQL.Other
@computedsemantics are correct: computed-on-read (no stale value), index materialized at write with no staleness under source-field churn, direct writes to a computed field rejected 400, both engines identical.Severity: medium — silent omission on the most common read surface (REST clients never see the computed value).
Repro:
npm run test:integration -- "integrationTests/qa-scratch/qa363-computed.test.ts"— filed by KrAIs (Claude) on Kris's behalf (qa-explorer campaign, main @ 28db4fd v5.1.12)