Feat: new column access mechanism#1620
Conversation
🦋 Changeset detectedLatest commit: e765c4f The changes in this PR will be included in the next version bump. This PR includes changesets to release 32 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors column handling and result pool logic to support lazy data status and efficient object discovery. It introduces PObjectFieldStatus to decouple data availability from accessor materialization and implements a raw result pool view for upstream blocks. The SDK has been updated to use the standard PColumn interface instead of ColumnSnapshot. Review feedback identifies critical bugs in AccessorColumnProvider regarding nested structure resolution and in isPColumnReady where readiness checks are skipped for "presented" status. Additionally, there is a fragile import from a dist directory and a logic error in mapping data status for resolving TreeNodeAccessor objects.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
AStaroverov
force-pushed
the
feat/new-column-access-mechanism
branch
from
0601340 to
44f864b
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #1620 +/- ##
==========================================
- Coverage 53.07% 52.60% -0.48%
==========================================
Files 270 284 +14
Lines 15719 16282 +563
Branches 3411 3606 +195
==========================================
+ Hits 8343 8565 +222
- Misses 6262 6579 +317
- Partials 1114 1138 +24 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
AStaroverov
force-pushed
the
feat/new-column-access-mechanism
branch
3 times, most recently
from
40ebdb7 to
61afec9
Compare
AStaroverov
force-pushed
the
feat/new-column-access-mechanism
branch
from
b3f266c to
c7309fc
Compare
AStaroverov
force-pushed
the
feat/new-column-access-mechanism
branch
from
d698e40 to
e222669
Compare
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
AStaroverov
force-pushed
the
feat/new-column-access-mechanism
branch
from
e222669 to
e765c4f
Compare
| if (resolvedIds.size === 0) { | ||
| throwError("At least one anchor must be resolved to a valid column"); | ||
| } |
There was a problem hiding this comment.
resolveAnchors throws in transient states, crashing the computable
When discover() is called with anchors but none of the specified anchor columns have arrived in the collection yet (e.g. an upstream block hasn't published its PFrame, but other upstream blocks have, so ids.length > 0 passes the early-exit guard), resolveAnchors throws "At least one anchor must be resolved to a valid column". This propagates as an uncaught exception through the QuickJS bridge, putting the computable into an error state rather than an incomplete/pending state. The correct behaviour in a non-final, non-empty collection is to return an empty minted collection (as is already done on line 258 for the zero-ids case).
The fix would be to return early in runDiscovery when resolveAnchors produces zero matches:
Prompt To Fix With AI
This is a comment left during a code review.
Path: lib/model/columns-collection-driver/src/driver.ts
Line: 438-440
Comment:
**`resolveAnchors` throws in transient states, crashing the computable**
When `discover()` is called with anchors but none of the specified anchor columns have arrived in the collection yet (e.g. an upstream block hasn't published its PFrame, but other upstream blocks have, so `ids.length > 0` passes the early-exit guard), `resolveAnchors` throws `"At least one anchor must be resolved to a valid column"`. This propagates as an uncaught exception through the QuickJS bridge, putting the computable into an error state rather than an incomplete/pending state. The correct behaviour in a non-final, non-empty collection is to return an empty minted collection (as is already done on line 258 for the zero-ids case).
The fix would be to return early in `runDiscovery` when `resolveAnchors` produces zero matches:
How can I resolve this? If you propose a fix, please make it concise.
2 participants
Greptile Summary
This PR introduces a new column-access mechanism for the Platforma SDK, replacing the previous ad-hoc column discovery with a structured
ColumnsCollectionabstraction backed by a host-sideColumnsCollectionDriverImpl. The new system supports anchored discovery (axis-aware linker traversal), selector filtering, spec override propagation, and a deduplication layer that collapses duplicate physical columns across sources.ColumnsCollectionDriver+ColumnsCollectionDriverImpl: opaque handle-based, refcounted collection objects; sources can be accessor trees, result-pool fan-outs, existing collections, or pre-resolved id lists.discover()andfilter()produce derivative collections via the spec driver.SpecOverrides/ColumnOverridedIdlayer: spec delta derivation, positional axis-patch merging, andcollapseSpecOverrideNodethat pushes overrides down tocolumnleaves before handing the query to pframe-engine.AccessorEntriesProvider/ResultPoolEntriesProvider: generic host-side and sandbox-side DFS-based column indexers withisFinal()derived from accessor lock state.Confidence Score: 3/5
The core abstraction is well-designed, but two defects in the new code can cause incorrect behavior during normal progressive data loading.
Two independent defects both affect the non-final (loading) phase. First,
resolveAnchorsunconditionally throws when no anchor column has arrived in the collection yet; this turns a transient incomplete state into a hard computation error. Second, the module-level_accessorProviderCachein the SDK is keyed by the stable "main"/"staging" handle string, so it returns stale column entries on every render after the first and stops the computable framework from re-registeringlistInputFieldsas a reactive dependency — newly added columns are silently missed until something else triggers a re-run.lib/model/columns-collection-driver/src/driver.ts(anchor resolution throwing) andsdk/model/src/columns/column_providers/providers.ts(stale LRU cache key)Important Files Changed
Sequence Diagram
sequenceDiagram participant Sandbox as Sandbox (SDK model) participant Bridge as VM Bridge (service_injectors) participant Driver as ColumnsCollectionDriverImpl participant Host as ColumnsCollectionDriverHost participant SpecDrv as PFrameSpecDriver Sandbox->>Bridge: columnsCollection.create(sources) Bridge->>Driver: create(sources, host) Driver->>Host: resolveAccessor / getUpstreamBlockCtxes Driver-->>Bridge: "PoolEntry<CollectionHandle>" Bridge-->>Sandbox: CollectionHandle (pinned to render ctx) Sandbox->>Bridge: "columnsCollection.discover(handle, {anchors, include})" Bridge->>Driver: discover(handle, options, host) Driver->>Host: resolveSpec(leafId) per id Driver->>SpecDrv: createSpecFrame(specMap) Driver->>Driver: resolveAnchors(anchors, specMap, specDrv) Driver->>SpecDrv: discoverColumns(frameKey, request) SpecDrv-->>Driver: DiscoverColumnsResponse Driver->>Driver: mapHitsWithDiscovery → ColumnUniversalId[] Driver-->>Bridge: "PoolEntry<CollectionHandle>" Bridge-->>Sandbox: new CollectionHandle Sandbox->>Bridge: columnsCollection.getColumns(handle) Bridge->>Driver: getColumns(handle, host) Driver->>Driver: dedupColumns(all contributions) Driver-->>Bridge: ColumnUniversalId[] Bridge-->>Sandbox: ColumnUniversalId[]Prompt To Fix All With AI
Reviews (4): Last reviewed commit: "feat: new column access mechanism" | Re-trigger Greptile