feat(source-stripe): expose supports_realtime_sync in catalog metadata#345
Merged
feat(source-stripe): expose supports_realtime_sync in catalog metadata#345
Conversation
There was a problem hiding this comment.
Pull request overview
Adds per-stream catalog metadata to indicate whether a Stripe table is updated via real-time webhooks, enabling destinations to distinguish webhook-backed streams from backfill-only streams.
Changes:
- Introduces
REALTIME_SYNC_TABLESas a canonical set of webhook-updated table names. - Sets
stream.metadata.supports_realtime_syncincatalogFromOpenApi()based onREALTIME_SYNC_TABLESmembership. - Adds unit tests covering one real-time stream (
subscriptions) and one list-only stream (reporting_report_types).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| packages/source-stripe/src/types.ts | Adds REALTIME_SYNC_TABLES to enumerate tables receiving webhook-driven updates. |
| packages/source-stripe/src/catalog.ts | Populates metadata.supports_realtime_sync for each discover stream. |
| packages/source-stripe/src/catalog.test.ts | Adds tests asserting the flag is true for a webhook-backed stream and false for a list-only stream. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
026644c to
c70a59b
Compare
Add a `supports_realtime_sync` boolean to each stream's metadata in the discover catalog. This lets destinations know which tables receive real-time updates via webhooks vs. tables that are backfill-only. A new `REALTIME_SYNC_TABLES` set in types.ts is derived from the existing SUPPORTED_WEBHOOK_EVENTS list. Two new tests verify the flag is true for webhook-backed tables and false for list-only tables. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com> Committed-By-Agent: claude
c70a59b to
b20f633
Compare
tonyxiao
approved these changes
Apr 28, 2026
tonyxiao
pushed a commit
that referenced
this pull request
Apr 28, 2026
#345) * feat(source-stripe): expose supports_realtime_sync in catalog metadata Add a `supports_realtime_sync` boolean to each stream's metadata in the discover catalog. This lets destinations know which tables receive real-time updates via webhooks vs. tables that are backfill-only. A new `REALTIME_SYNC_TABLES` set in types.ts is derived from the existing SUPPORTED_WEBHOOK_EVENTS list. Two new tests verify the flag is true for webhook-backed tables and false for list-only tables. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com> Committed-By-Agent: claude * step one, remove the fan out of discover list... * unify discover pipeline, fuse schema into registry, single-arg catalogFromOpenApi * use bundled version * skip version with no webhook info * use enabled events to discover webhook supported objects * v2 webhooks * catalog snap --------- Co-authored-by: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: Yostra <straya.mark@gmail.com>
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
The Stripe source
discover()had two independent discovery paths that each walked the OpenAPI spec separately, applied different inclusion logic, produced different output shapes, and were then joined by a fragile name-based intersection:Neither side owned both concerns:
buildResourceRegistrywas the source of truth for what can be synced (it has the runtime list/retrieve functions), whileSpecParserwas the source of truth for what should be synced (webhook filter + schema). The two were glued together by a name-basedMap.get()that could silently produce streams without schemas ("ghost tables") or quietly drop tables when the two sets disagreed.Solution
Establish a single linear pipeline where each step feeds the next, rather than two parallel paths joined at the end.
Before
flowchart TB spec[OpenAPI spec] spec --> left["buildResourceRegistry(spec)"] spec --> right["SpecParser.parse(spec)"] left --> reg["registry — runtime fns per table"] right --> tables["parsed.tables — schemas per table"] reg --> cfo["catalogFromOpenApi(tables, registry)"] tables --> cfo cfo -->|"join by name"| catalog["catalog.streams"]Two independent walks of the spec, joined by name at the end.
After
flowchart TB spec[OpenAPI spec] spec --> ps["parser.parseSyncable(spec, {excluded})"] ps --> parsed["parsed.tables — syncable tables with schemas"] parsed --> brr["buildResourceRegistry(spec, ..., parsedTables)"] spec --> brr brr --> reg["registry — runtime fns + schema per entry"] reg --> cfo["catalogFromOpenApi(registry)"] cfo --> catalog["catalog.streams"]Single linear flow. No parallel discovery, no name-based join.
What changed
SpecParser.parseSyncable()— new method that fusesdiscoverSyncableTables+parseinto one call. The canonical "what should be synced" decision happens once, here.parsedTableonResourceConfig— each registry entry now carries its own parsed schema, attached at build time. The schema travels with the runtime functions instead of being looked up by name later.catalogFromOpenApi(registry)— takes one argument instead of two. No moreMap.get()join. Each entry already has everything needed to emit a stream. Throws ifparsedTableis missing (ghost-table guard moved here).