chore: update schemas from constructive-db - #1778
Conversation
Auto-generated by schema-propagation workflow. Source: constructive-db@a6bf45dbfbf
|
Review complete. 🟠 2 high · 🟡 1 medium 💬 Inline comments (3)
This is a large auto-generated codegen regeneration (2,489 files) that updates the GraphQL schemas and re-emits the ORM clients, CLI commands, and React hooks across constructive-sdk, constructive-cli, and constructive-react. The substantive changes are the addition of new compute (cluster/image/machine), storage, and remote ORM modules with realtime support, new agent fields (kind, visibility, databaseId, principal columns), and the admin permissions-to-capabilities rename.
Note: the holistic, sweep, and two per-lens scan passes hit their step caps and did not publish; findings reflect the six scanner artifacts that did publish. Reviewed commit: d509b07 |
![tenki-reviewer[bot]](https://avatars.githubusercontent.com/in/2900641?s=60&v=4){kind=small}
There was a problem hiding this comment.
Regenerates all SDK clients and GraphQL schemas from updated schemas, adding new compute/storage/remote ORM modules, new agent fields, and renaming the admin permissions surface to capabilities.
Key findings
- 🟠 Search where-clause keys mismatch filter types — platform-proposal-comment.ts:191
- 🟠 MachineMessage input omits required
recordedAt— input-types.ts:786 - 🟡 Realtime connection state never transitions — realtime.ts:143
| const searchWhere = { | ||
| embedding: { | ||
| vector: query, | ||
| }, | ||
| trgmBody: { | ||
| value: query, | ||
| threshold: 0.3, | ||
| }, | ||
| trgmPath: { | ||
| value: query, | ||
| threshold: 0.3, | ||
| }, | ||
| search: { | ||
| query, | ||
| }, | ||
| }; |
There was a problem hiding this comment.
🟠 bug · high
Search where-clause keys mismatch filter types
The generated search/list commands build searchWhere with embedding: { vector: query } and search: { query }, but the ORM filter types define embedding as VectorFilter (no vector field) and search as FullTextFilter (only matches) (sdk/constructive-cli/src/compute/cli/commands/platform-proposal-comment.ts:191). Vector similarity search belongs on the separate vectorEmbedding: VectorNearbyInput field, so the generated filter is invalid and the search command is rejected by the GraphQL API at runtime. The same issue appears in proposal-comment.ts, platform-proposal.ts, proposal.ts, proposals-chunk.ts, platform-proposals-chunk.ts, repository.ts, and platform-repository.ts.
📋 Prompt for AI Agents
In sdk/constructive-cli/src/compute/cli/commands/platform-proposal-comment.ts (searchWhere block, lines 191-206) and the identical blocks in proposal-comment.ts, platform-proposal.ts, proposal.ts, proposals-chunk.ts, platform-proposals-chunk.ts, repository.ts, and platform-repository.ts, fix the search where clause to match the ORM filter types: replace embedding: { vector: query } with vectorEmbedding: { vector: query } (the vectorEmbedding field is VectorNearbyInput; embedding is only VectorFilter with no vector key), and replace search: { query } with search: { matches: query } (the search field is FullTextFilter which only exposes matches). Also update the autoEmbedWhere(searchWhere ?? {}, ['embedding'], embedder) calls to target ['vectorEmbedding'] so the string query is embedded into the correct field. This makes the generated search/list commands send a filter the GraphQL API accepts instead of one that is rejected at runtime.
| export interface UpdateMachineMessageInput { | ||
| clientMutationId?: string; | ||
| id: string; | ||
| machineMessagePatch: MachineMessagePatch; | ||
| } | ||
| export interface DeleteMachineMessageInput { | ||
| clientMutationId?: string; | ||
| id: string; | ||
| } |
There was a problem hiding this comment.
🟠 bug · high
MachineMessage input omits required recordedAt
The generated UpdateMachineMessageInput/DeleteMachineMessageInput types declare only id (sdk/constructive-cli/src/remote/orm/input-types.ts:786), yet the remote schema requires recordedAt: Datetime! on both mutations and the model injects recordedAt into the payload (machineMessage.ts:202). Consumers building these inputs from the generated types cannot supply the required partition key, so update/delete on MachineMessage fail with a missing-argument error and the README where: { id } examples do not compile against the model signature. The same mismatch exists in sdk/constructive-sdk/src/remote/orm/input-types.ts.
📋 Prompt for AI Agents
In sdk/constructive-cli/src/remote/orm/input-types.ts around lines 786-794 (and the matching sdk/constructive-sdk/src/remote/orm/input-types.ts), add recordedAt: string; to both the UpdateMachineMessageInput interface and the DeleteMachineMessageInput interface, because the remote.graphql schema requires recordedAt: Datetime! on both mutations (UpdateMachineMessageInput line 2330, DeleteMachineMessageInput line 262) and the generated MachineMessageModel.update/delete (sdk/constructive-cli/src/remote/orm/models/machineMessage.ts lines 174-240) require a recordedAt composite partition key in the where and inject it into the mutation input payload. Without it the declared input types contradict the schema and the serialized request, so update/delete calls fail at runtime and README where: { id } examples will not compile.
| private connectionState: ConnectionState = 'disconnected'; | ||
| private stateListeners: Set<ConnectionStateListener> = new Set(); |
There was a problem hiding this comment.
🟡 bug · medium
Realtime connection state never transitions
RealtimeManager tracks a ConnectionState initialized to 'disconnected' that is only ever changed inside dispose() (sdk/constructive-cli/src/storage/orm/realtime.ts:234), because setConnectionState() is never wired to the underlying wsClient's connecting/connected/reconnecting lifecycle (the WsClient interface exposes only subscribe()/dispose(), line 31). As a result getConnectionState() always returns 'disconnected' even while events are delivered, and every onConnectionStateChange listener is dead until dispose; consumers gating upload/retry logic on 'connected' state misbehave and can never observe a healthy connection. The same defect exists in sdk/constructive-sdk/src/remote/orm/realtime.ts.
📋 Prompt for AI Agents
In sdk/constructive-cli/src/storage/orm/realtime.ts (and the matching sdk/constructive-sdk/src/remote/orm/realtime.ts), the private connectionState (line 143) is never updated except in dispose() (line 234). Extend the WsClient interface (or accept an optional onConnectionStateChange in RealtimeConfig) so the manager can observe the transport's connecting/connected/reconnecting states, then call this.setConnectionState() on those transitions in the constructor and remove the hook in dispose(), so getConnectionState() and onConnectionStateChange listeners reflect the real WebSocket state.
|
Found 4 test failures on Blacksmith runners: Failures
|
![Fix with [code]smith](https://pr-comments-assets.blacksmith.sh/codesmith/fix-with-codesmith-light.png)
1 participant
Automated Schema + SDK Update
This PR was created by the schema-propagation workflow.
What changed
Updated schema files from constructive-db and regenerated ALL SDK clients.
Source:
constructive-db@a6bf45dbfbfSchemas updated
sdk/constructive-sdk/schemas/— all API targets from constructive-db (auto-discovered)sdk/migrate-client/schemas/— migratepgpm/export/src/meta-export-tables.json— generated meta export table listClients regenerated
sdk/constructive-sdk/src/— ORM clientsdk/constructive-cli/src/— CLI clientsdk/constructive-react/src/— React hookssdk/migrate-client/src/— Migrate clientSkill references updated
.agents/skills/— Generated skill documentationAuto-generated by constructive-hub schema-propagation