chore: update sdk-compliance.yaml for renamed capability matrix IDs - #1666
Closed
grdsdev wants to merge 2 commits into
Closed
chore: update sdk-compliance.yaml for renamed capability matrix IDs#1666grdsdev wants to merge 2 commits into
grdsdev wants to merge 2 commits into
Conversation
supabase/sdk#74 renames/splits several feature IDs. Updates references here so CI's capability compliance validator doesn't fail on unknown IDs: - auth.sign_in.reset_password -> auth.sign_in.send_password_reset_email - realtime.channel.send -> realtime.channel.broadcast - storage.file_buckets.list_files_paginated merged into list_files - storage.analytics.iceberg_namespace split into create_namespace/list_namespaces/delete_namespace - storage.analytics.iceberg_table split into create_table/list_tables/load_table/update_table/rename_table/delete_table No SDK code changes — only the capability declarations. See supabase/sdk#74 and https://linear.app/supabase/issue/SDK-1439 for context.
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe compliance manifest renames three capability IDs, moves the storage file-listing symbol, and splits bundled Iceberg namespace and table capabilities into operation-specific entries. ChangesSDK capability alignment
Estimated code review effort: 4 (Complex) | ~45 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Tr00d
approved these changes
Aug 7, 2026
spydon
reviewed
Aug 7, 2026
| storage.analytics.iceberg_table: | ||
| storage.analytics.create_table: | ||
| status: implemented | ||
| note: "Mechanical split of the previously bundled iceberg_table entry — symbols below cover the whole table surface (create, list, load, update, rename, drop) and have not been divided per-operation yet. Data definition table updates (schema, partition spec, sort order, properties, location) are modelled as typed TableUpdate subclasses; snapshot, statistics and encryption key updates are sent through the TableUpdate.raw escape hatch." |
Contributor
There was a problem hiding this comment.
These type of notes should not be in here imho
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
sdk-compliance.yaml (1)
1088-3091: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDeduplicate the table capability symbol lists.
The six table capabilities share the same
noteand ~330-entrysymbolslist. Any future symbol addition must be applied in six places, which creates drift risk. Use separate source data or a shared YAML anchor if the validator resolves anchors correctly.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@sdk-compliance.yaml` around lines 1088 - 3091, Deduplicate the repeated table capability definitions by introducing one shared source for their common note and symbols list, preferably a YAML anchor or validator-supported shared data. Update all six capabilities, including storage.analytics.create_table and storage.analytics.list_tables, to reference that shared definition while preserving their individual statuses and capability keys.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@sdk-compliance.yaml`:
- Around line 1088-3091: Deduplicate the repeated table capability definitions
by introducing one shared source for their common note and symbols list,
preferably a YAML anchor or validator-supported shared data. Update all six
capabilities, including storage.analytics.create_table and
storage.analytics.list_tables, to reference that shared definition while
preserving their individual statuses and capability keys.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 34969027-a134-4ec4-a7cf-2360d9bb538a
📒 Files selected for processing (1)
sdk-compliance.yaml
Contributor
There was a problem hiding this comment.
Pull request overview
Updates this repository’s sdk-compliance.yaml capability IDs to match the renamed/split feature IDs in the upstream canonical capability matrix, preventing the SDK compliance CI check from failing on unknown IDs. This stays within the repo’s compliance-metadata layer (no SDK implementation changes).
Changes:
- Renamed capability IDs for auth password reset and realtime broadcast to match the updated matrix.
- Consolidated storage file listing pagination under
storage.file_buckets.list_fileswith an updated note. - Split the previous Iceberg namespace/table capability IDs into per-operation IDs, duplicating the prior symbol sets across the new entries with explicit notes.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Per review: the "mechanical split, not yet divided per-operation" explanations don't belong in a compliance file meant to describe SDK behavior, not how this PR was authored. Removed them from all nine split entries. Kept the one substantive note (TableUpdate subclasses vs. the .raw escape hatch) on update_table, since that's genuine implementation detail carried over from the original bundled entry.
Contributor
|
Superseded by #1667 |
spydon
added a commit
to supabase/sdk
that referenced
this pull request
Aug 7, 2026
## Problem The `symbols` list in `sdk-compliance.yaml` feeds two checks that want opposite things: | Check | Reads `symbols` as | Wants | |---|---|---| | `checkDrift` | **Evidence** that a capability is implemented | A short, precise list of entry points, all of which must exist | | `checkNewSymbols` | **Coverage**, so no new public API slips in unclassified | An exhaustive account of the entire public surface | One list cannot serve both. When a capability's supporting types outnumber its methods, authors get pushed into one of two workarounds: 1. Padding `symbols` with option types, result types and exceptions that do not implement anything, or 2. Repeating one shared symbol list across several features so each has something to point at. Both inflate what the matrix claims is implemented, fan drift warnings out across features that do not own the symbol, and leave symbol-to-feature attribution arbitrary, since `buildSymbolIndex` silently last-wins on collision. This is not hypothetical. supabase/supabase-flutter#1666 hit it head-on: reconciling #74 required replicating a 330-symbol Iceberg list across 6 new feature IDs and a 22-symbol list across 3 more, for +1729 lines. Every one of those 330 symbols now resolves to `storage.analytics.delete_table` in the symbol index, purely because it sorts last. The existing escape hatches do not help. `@internal` and `.sdk-parse-ignore` remove symbols from the surface entirely, but types like `TableMetadata` are genuinely public API that consumers construct. They just are not *capabilities*. ## Change Adds an optional `supporting_symbols` list, per feature and top level, that counts for new-symbol coverage and is never drift-verified: ```yaml storage.analytics.create_table: status: implemented symbols: - IcebergRestCatalog.createTable # evidence, drift-verified supporting_symbols: - CreateTableRequest # coverage only supporting_symbols: # top level, shared across features - IcebergException ``` - `compliance.ts`: new field on `RawValue` and `RawCompliance`; validation extracted into a shared `checkSymbolList` helper so both lists get identical treatment; `normalizeCompliance` preserves it; `buildSymbolIndex` unions both. Entry points are indexed **last**, so a symbol listed both ways is attributed to the capability that implements it rather than to a supporting bucket. Top-level entries index against an exported `TOP_LEVEL_SUPPORTING` sentinel so removal messages stay readable. - `drift-check.ts`: **unchanged**. It already read only `value.symbols`, so the separation falls out for free. - `api-check.ts`: the failure message now teaches the distinction, since that message is exactly where an author hits this wall. - `types.ts`, `docs/capability-matrix.md`, tests. ## Compatibility The field is optional and the drift check already ignored anything outside `symbols`, so existing compliance files are unaffected. Verified that supabase-flutter's current `sdk-compliance.yaml` validates unchanged. ## Test plan - [x] 194 tests pass; 12 new, including the two that pin the semantics: supporting symbols do not satisfy drift on their own, and a missing supporting symbol produces no drift finding. - [x] `tsc --noEmit` clean. - [x] `npm run validate` still OK on the canonical registry. - [x] Rebuilt supabase-flutter#1666's Iceberg entries in this shape as a check that it solves the motivating case: 0 drift findings, 0 uncovered symbols out of 352, attribution exact (`createTable` maps to `create_table`, not `delete_table`), and **2046 symbol lines become 352**. ## Follow-ups, deliberately not in this PR - **Reject duplicate symbol registration.** Now that supporting types have a home this becomes viable, and it would have caught supabase-flutter#1666's shape automatically. Turning it on today would fail existing compliance files, so it needs its own migration. - **`renamed_from` aliases on canonical features.** Separate concern and arguably higher value: today every ID rename here breaks all seven SDK repos at once, with no window in which both old and new IDs validate, because each repo pins the reusable workflow at `@main`. - **The registry is narrower than the SDKs.** #74 splits namespaces into create/list/delete, but the real Flutter surface has seven namespace operations. `loadNamespaceMetadata`, `namespaceExists`, `updateNamespaceProperties`, `registerTable` and `tableExists` map to no capability at all. This PR gives them an honest home rather than a false claim, but the underlying gap is worth deciding on separately.
spydon
added a commit
that referenced
this pull request
Aug 7, 2026
…nd splits (#1667) ## Summary Reconciles `sdk-compliance.yaml` with three upstream changes that have now landed in `supabase/sdk`: - **supabase/sdk#74** renamed and split several canonical feature IDs. - **supabase/sdk#75** separated symbol *evidence* from symbol *coverage*, adding `supporting_symbols`. - **supabase/sdk#76** added the five Iceberg catalog capabilities that #74's split left without an ID. ### Renames and merges - `auth.sign_in.reset_password` → `auth.sign_in.send_password_reset_email` - `realtime.channel.send` → `realtime.channel.broadcast` - `storage.file_buckets.list_files_paginated` merged into `list_files` - `storage.analytics.iceberg_namespace` split into `create_namespace` / `list_namespaces` / `delete_namespace` - `storage.analytics.iceberg_table` split into `create_table` / `list_tables` / `load_table` / `update_table` / `rename_table` / `delete_table` ### New capabilities declared `load_namespace_metadata`, `namespace_exists`, `update_namespace_properties`, `register_table`, `table_exists`. ## Why the Iceberg entries look the way they do Splitting two bundled entries into fifteen raises the question of which symbols belong where. The Iceberg surface is 352 symbols, only 18 of which are catalog entry points; the rest are option types, result types, the schema and type model, and the exception hierarchy. `symbols` now holds **only** the methods a caller invokes, because the drift check treats every name in it as evidence the capability exists. Everything else sits under `supporting_symbols`, which counts for new-symbol coverage without claiming to implement anything. Owners for the supporting types are derived from the source rather than assigned by hand: build the type graph from `packages/storage_client/lib/src/iceberg/`, including subtype edges since a signature naming a sealed base reaches every variant a caller can pass, then ask which entry points reach each type. A type reachable from exactly one feature belongs to that feature. | | count | |---|---| | Sole natural owner | 37 of 67 | | Genuinely shared across several features | 20 | | Reachable from no entry point (thrown, not passed) | 10 | So all 28 `*Update` and `Assert*` classes land on `update_table`, `ListTablesOptions`/`ListTablesResult` on `list_tables`, `RegisterTableRequest` on `register_table`. The schema and type model and the exception hierarchy stay in the top-level `supporting_symbols` list, which is the honest answer rather than a coin flip. The alternative was to replicate the full 330-symbol list across all six table IDs and the 22-symbol list across all three namespace IDs (+1729 lines, as in the now-closed #1666). That inflates what the file claims is implemented, fans drift findings across features that do not own the symbol, and leaves attribution arbitrary, since `buildSymbolIndex` last-wins on collision. Under that shape only 2 of 9 split features resolved to their own entry point; here it is 9 of 9. ## Test plan Validated against current `supabase/sdk@main`, with #74, #75 and #76 all merged: - [x] `validate-compliance`: `OK — compliance file is valid.` Two features remain undeclared (`postgres_changes_multiple_filters`, `error_codes`); both are pre-existing and out of scope here. - [x] `check-drift` against symbols extracted with the real Dart extractor: `✅ No capability matrix drift detected.` - [x] `check-api-symbols`: all public API accounted for; 887 symbols covered, unchanged from before this PR. - [x] Verified no unintended edits: every feature outside the rename and split scope is byte-identical to `main` after re-serialization. - [x] CI re-run after the upstream merges: `Validate compliance file` and `Check public API against capability matrix` both green. No SDK code changes, only capability declarations. Context: [SDK-1439](https://linear.app/supabase/issue/SDK-1439) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Improvements** * Standardized capability names for password reset and realtime broadcast functionality. * Clarified storage file listing capabilities, including pagination and sorting support. * Added more granular capability definitions for Iceberg namespaces and tables. * Consolidated shared Iceberg models, errors, catalog access, and supporting symbols for more consistent capability descriptions. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
supabase/sdk#74 renames/splits several feature IDs in the canonical capability matrix. This updates
sdk-compliance.yamlso the SDK compliance CI check doesn't fail on unknown IDs once that PR merges. No SDK code changes.auth.sign_in.reset_password→auth.sign_in.send_password_reset_emailrealtime.channel.send→realtime.channel.broadcaststorage.file_buckets.list_files_paginatedmerged intolist_files(symbols combined)storage.analytics.iceberg_namespacesplit intocreate_namespace/list_namespaces/delete_namespacestorage.analytics.iceberg_tablesplit intocreate_table/list_tables/load_table/update_table/rename_table/delete_tableFor both Iceberg splits, the full original symbol list is replicated across every new ID rather than hand-divided per operation — a
noteon each entry says this explicitly. This SDK's Iceberg symbol list is large and granular enough (per-method names likecreateNamespace/dropNamespace/listTables/updateTable) that a precise per-operation split is very doable, but I didn't want to guess at attributing ~330 shared/supporting type symbols (schema types, exceptions, request/result classes) to one verb over another without a maintainer's sign-off. Flagging this as a good follow-up for someone closer to the code.Context: SDK-1439
Test plan
npm run validate-compliancefromsupabase/sdk(branch with chore: publish 0.3.0 #74's changes):OK — compliance file is valid.Summary by CodeRabbit