chore: reconcile sdk-compliance.yaml with capability matrix renames and splits - #1667
Conversation
Alternative to #1666, for comparison. Applies the same five renames from supabase/sdk#74, but splits the Iceberg entries using the entry-point and supporting-symbol distinction proposed in supabase/sdk#75 instead of replicating one symbol list across every new feature id. - 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/list/delete - storage.analytics.iceberg_table split into create/list/load/update/rename/delete `symbols` now holds only the methods a caller invokes, which is what the drift check verifies. Option and result types sit under the feature's `supporting_symbols`. The Iceberg type model, the exception hierarchy and the operations the canonical matrix has no id for are listed once at the top level rather than attributed to a verb they do not belong to. Depends on supabase/sdk#74 and supabase/sdk#75.
|
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 SDK compliance matrix renames canonical capability IDs, consolidates storage listing symbols, splits Iceberg namespace and table operations, and moves shared Iceberg symbols into a top-level ChangesCompliance matrix alignment
Estimated code review effort: 4 (Complex) | ~45 minutes Possibly related PRs
🚥 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 |
Derives each supporting type's owner from the source rather than by hand: a type reachable from exactly one feature's entry points belongs to that feature. 35 of 67 Iceberg types now have a single natural owner. Types reachable from several features (the schema and type model) or from none because they are thrown rather than passed (the exception hierarchy) stay at the top level.
Every Iceberg catalog operation now has a feature id, so loadNamespaceMetadata, namespaceExists, updateNamespaceProperties, registerTable and tableExists move out of the top-level supporting bucket into entries of their own. That also gives RegisterTableRequest and UpdateNamespacePropertiesResult a real owner, leaving nothing at the top level but genuinely shared types.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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.
Inline comments:
In `@sdk-compliance.yaml`:
- Line 767: The YAML incorrectly places paginated file-listing symbols under
storage.file_buckets.list_files. Add a separate
storage.file_buckets.list_files_paginated capability, move
StorageFileApi.listPaginated and its pagination options/result symbols there,
and keep StorageFileApi.list mapped only to storage.file_buckets.list_files.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 92cc57ad-86ee-4877-a772-65477aae3ac4
📒 Files selected for processing (1)
sdk-compliance.yaml
The merged list_files entry kept every symbol from the old paginated entry under `symbols`, so the option, result and sort types counted as evidence the capability exists. Only StorageFileApi.list and listPaginated are entry points; the rest move to supporting_symbols. Also restores the note to its usual position after status, where the serializer had appended it to the end of the entry.
Summary
Reconciles
sdk-compliance.yamlwith three upstream changes that have now landed insupabase/sdk:supporting_symbols.Renames and merges
auth.sign_in.reset_password→auth.sign_in.send_password_reset_emailrealtime.channel.send→realtime.channel.broadcaststorage.file_buckets.list_files_paginatedmerged intolist_filesstorage.analytics.iceberg_namespacesplit intocreate_namespace/list_namespaces/delete_namespacestorage.analytics.iceberg_tablesplit intocreate_table/list_tables/load_table/update_table/rename_table/delete_tableNew 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.
symbolsnow holds only the methods a caller invokes, because the drift check treats every name in it as evidence the capability exists. Everything else sits undersupporting_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.So all 28
*UpdateandAssert*classes land onupdate_table,ListTablesOptions/ListTablesResultonlist_tables,RegisterTableRequestonregister_table. The schema and type model and the exception hierarchy stay in the top-levelsupporting_symbolslist, 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
buildSymbolIndexlast-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: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.check-driftagainst symbols extracted with the real Dart extractor:✅ No capability matrix drift detected.check-api-symbols: all public API accounted for; 887 symbols covered, unchanged from before this PR.mainafter re-serialization.Validate compliance fileandCheck public API against capability matrixboth green.No SDK code changes, only capability declarations.
Context: SDK-1439
Summary by CodeRabbit