Skip to content

feat(controlplane): serve persons_distinct_ids_table in discovery payload - #1026

Draft
fuziontech wants to merge 1 commit into
mainfrom
james/discovery-persons-distinct-ids
Draft

feat(controlplane): serve persons_distinct_ids_table in discovery payload#1026
fuziontech wants to merge 1 commit into
mainfrom
james/discovery-persons-distinct-ids

Conversation

@fuziontech

Copy link
Copy Markdown
Member

What

Adds persons_distinct_ids_table to the per-team payload served by GET /api/v1/warehouses (destination discovery for external writers).

Why

Streamed persons replication (millpond → shared DuckLake changelog → viaduck full_cdc fanout) lands two tables per team in the duckling: the persons table and its distinct-id mapping table (the join side of today's denormalized batch export). Discovery already resolves events_table/persons_table; the distinct-ids location belongs in the same single derivation site so a viaduck persons pipeline never re-derives the suffix rule itself.

Derivation rule

resolveTeamTables now also returns <schema_name>. + the resolved persons name with its persons prefix replaced by persons_distinct_ids:

  • personspersons_distinct_ids
  • persons_ab12 (suffixed override) → persons_distinct_ids_ab12
  • an override without the persons prefix → <name>_distinct_ids

No new configstore column: this table has no legacy/grandfathered shape, so convention-only derivation is sufficient.

Compatibility

Additive field on the existing team payload — wire-compatible per the discovery module's own contract (adding a field is safe, removing one is not).

Tests

  • TestResolvedTableNames extended to assert the default derivation
  • New TestResolvedDistinctIDsTableFollowsPersonsSuffix for the suffixed-override case
  • go test ./controlplane/... green; golangci-lint run clean

🤖 Prepared by an agent as part of the persons-backfill → millpond/viaduck streaming migration.

…load

Streamed persons replication (millpond -> shared DuckLake changelog ->
viaduck full_cdc fanout) lands two tables per team in the duckling: the
persons table and its distinct-id mapping table. Destination discovery
already resolves events_table/persons_table; add the distinct-ids
location, derived once in resolveTeamTables from the resolved persons
name (persons_ab12 -> persons_distinct_ids_ab12), so a viaduck persons
pipeline never re-derives the suffix rule itself.

Wire-compatible: additive field on the existing team payload.
Co-authored-by: Shelley <shelley@exe.dev>
@github-actions

github-actions Bot commented Aug 3, 2026

Copy link
Copy Markdown

Test Impact Plan

Deterministic summary of how this PR changes tests, CI runners, and coverage-risk signals.

Summary

Area Added Changed Deleted
Test files 0 1 0
E2E/journey files 0 0 0
Workflow files 0 0 0

Signals

  • Test cases: +1 / -0
  • Assertions: +2 / -0
  • Skips or known failures added: 0
  • Workflow continue-on-error added: 0
  • Workflow path filters added: 0
  • Test commands removed from justfile: 0
  • E2E/journey retry lines added: 0

Coverage risk: neutral or increased

No coverage-reduction warnings detected.

Copy link
Copy Markdown
Member Author

Downstream consumer of this field: PostHog/posthog#76997 (duckling persons streaming schema prep + cutover runbook) derives the same name with persons_distinct_ids_table_name(), documented as rule-for-rule identical to distinctIDsTableName here. A prepared viaduck branch adds discovery.table_field so a persons pipeline can select persons_table / persons_distinct_ids_table from this payload.

Copy link
Copy Markdown
Member Author

Full PR map for the persons streaming migration:

Note: the millpond side needs nothing — its person / person-distinct-id consumers already land the changelogs on megaduck in prod.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant