Uh oh!
There was an error while loading. Please reload this page.
fix(objectql): thread execution context into read-time formula evaluation - #1988
Merged
Conversation
…tion (#1979) `applyFormulaPlan` computes Field.formula virtual fields after find/findOne, but evaluated each expression with only `{ record }`. So a formula using now()/today() ran against a fresh wall-clock read on every evaluation (no determinism), and a formula referencing the caller (os.user.id / os.org.id) faulted and fell back to null because user/org were never in scope. Build the eval context the same way applyFieldDefaults already does: a `now` snapshot pinned once per operation (every row + every formula field in one read observes the same instant) plus os.user / os.org resolved from the ExecutionContext. The two call sites in find()/findOne() pass opCtx.context. Independent of timezone; the read-path prerequisite for ADR-0053 Phase 2 (#1980 will additionally thread `timezone` here once ExecutionContext.timezone exists). Tests: read-time formula resolves os.user.id/os.org.id from context; `now()` is pinned identically across all rows in one find. Full objectql suite green (639). Closes#1979. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
📓 Docs Drift CheckThis PR changes 1 package(s): 14 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
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
1 participant
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.
Closes#1979.
What
applyFormulaPlan— which computesField.formulavirtual fields afterfind/findOne— evaluated each expression with only{ record }:So:
now()/today()ran against a fresh wall-clock read on every evaluation — no determinism within one read;os.user.id,os.org.id) faulted and fell back tonull, because user/org were never in scope.Fix
Build the eval context exactly the way
applyFieldDefaultsalready does — anowpinned once per operation (every row and every formula field in one read observes the same instant) plusos.user/os.orgresolved from theExecutionContext:The two call sites in
find()/findOne()passopCtx.context(already in scope). Read-time formulas now behave consistently with default-value expressions.Scope
This is the read-path slice of ADR-0053 Phase 2 (#1975), but it is independent of timezone and valuable on its own (determinism + caller-aware computed fields). #1980 will additionally thread
timezonehere onceExecutionContext.timezoneexists.Testing
os.user.id/os.org.idfrom the execution context;now()is pinned identically across all rows in onefind.@objectstack/objectqlsuite green — 639 tests; DTS build + typecheck clean.patch(lockstep fixed group).🤖 Generated with Claude Code