feat(warehouse): cover 258 warehouse source kinds - #1145
Conversation
Intercom, Plain and Polar sit behind the dwh_intercom, dwh_plain and dwh_polar feature flags. Most users cannot finish the setup the wizard offers, and in two weeks the wizard spent 42 offers on them. The wizard cannot read those flags. It reads a flag snapshot, but that snapshot comes from the wizard's own telemetry project, not the user's PostHog project. The MCP has no flag-check tool either. So a per-entry gate would have nothing to evaluate. Remove the three entries and keep one comment that names the flags, so we can restore them later.
The registry covered 189 of the released data warehouse source types. This adds 69 more, so the wizard now recognises 255 kinds. The new entries cover databases (Firebase, Neon, PlanetScale MySQL, DynamoDB, MotherDuck, Databricks, SingleStore), LLM and AI tools, payments, email, comms, dev and infrastructure services, forms and productivity tools. Google Sheets was the last missing featured GA source. Every entry is in-cli. None of these sources has an OAuth-only field, so the agent can collect the credentials in the terminal. Also tell the agent to send the kind string, not the display label, as source_type. PostHog rejects the label.
🧙 Wizard CIRun the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands: Test all apps:
Test all apps in a directory:
Test an individual app:
Show more apps
Results will be posted here when complete. |
![veria-ai[bot]](https://avatars.githubusercontent.com/in/1723776?s=60&v=4){kind=small}
| { | ||
| kind: 'Firebase', | ||
| label: 'Firebase', | ||
| mode: 'in-cli', |
There was a problem hiding this comment.
Medium: Credentials enter the model context
A malicious repository can add one of these package or environment-key signals and cause the wizard to request credentials for the detected source. The released warehouse skill collects credentials for every in-cli source as non-sensitive text because the PostHog creation tools reject secret-vault references, so the resulting API keys and passwords are returned directly to the agent and sent through the model context. This applies to all newly added in-cli entries; keep them on the deep-link path until source creation accepts an opaque credential reference or another host-side handoff that never exposes the plaintext to the agent.
There was a problem hiding this comment.
The finding is accurate, but it describes the existing design of the whole in-cli path. This PR does not introduce it.
The registry already holds 172 in-cli entries that collect credentials the same way. The reason is upstream: external-data-sources-create rejects secret-vault references, so the skill must collect plain-text values to pass to it. That constraint is documented in the warehouse skill, not accidental.
Moving only the new entries to deep-link would make them behave differently from every comparable existing source, and would stop the wizard connecting any of them from the terminal. That is the feature. It would also leave the 172 existing entries exposed, so it does not close the gap it names.
The real fix belongs in PostHog: source creation needs to accept an opaque credential reference. Tracked separately in PostHog/posthog#89015, with production evidence from agents that hit this.
Keeping the new entries on in-cli here.
PR overviewThis pull request expands the warehouse source registry to cover 255 source kinds and removes the three previously flag-gated entries. It also configures how newly recognized sources are handled during warehouse setup. One security issue remains open: newly added in-CLI source flows can collect API keys and passwords as plain text and expose them to the model context. A malicious repository can influence source detection and induce the wizard to request those credentials, creating a concrete credential-disclosure path; no issues have yet been addressed. Open issues (1)
Fixed/addressed: 0 · PR risk: 8/10 |
This reverts commit 680e7aa. The removal rested on a wrong reading. Intercom, Plain and Polar each declare a feature flag in the source catalog, and I treated the presence of the flag name as proof the source was gated. A flag name says nothing about who the flag lets through. All three flags are active, cover one group at 100 percent, and carry no property targeting: dwh_plain 654465 dwh_intercom 682662 dwh_polar 682661 So all three sources reach every user, and the wizard should keep detecting them. The 42 offers in two weeks were correct, not wasted. Restore the three detectors, and restore Plain to SELF_DRIVING_TOOL_KINDS. The test that asserted the three were absent now asserts the opposite, so the next reader sees why a declared flag is not a gate.
Gilbert09
changed the title
1 participant
Problem
The detection registry knew 189 of PostHog's released data warehouse source
types. Users of the other released sources got no offer at all.
GoogleSheetswas the only
featuredGA source that was missing.An earlier revision of this PR also removed the
Intercom,PlainandPolardetectors, because the catalog lists a
dwh_intercom,dwh_plainordwh_polarfeature flag against each one. That was wrong, and commitbd840d6breverts it.A flag name says nothing about who the flag lets through. All three flags are
active, cover a single group at 100 percent, and carry no property targeting:
dwh_plain(654465),dwh_intercom(682662) anddwh_polar(682661). Everyuser can reach all three sources, so the wizard should keep detecting them.
Changes
Databricks, SingleStore.
Flutterwave, Dodo Payments, Whop.
Plunk, Ortto, Postscript, Marketo, Lob.
Railway, Render, Fly.io, Heroku, DigitalOcean, Grafana, Better Stack,
Honeycomb, Descope, FusionAuth, Hookdeck, n8n, dbt, Fastly, Bunny.net,
Codecov, Sourcegraph, Temporal.io, Hatchet.
GitBook, WordPress, Clockify, DocuSign, PandaDoc, Gong.
in-cli. None of these sources has an OAuth-only field, sothe agent can collect the credentials in the terminal.
kindstring assource_type, never the displaylabel. PostHog rejects the label, for example
Hugging FaceagainstHuggingFace.Every package name was checked against the npm registry, PyPI and RubyGems.
Every
kindwas checked against the live source catalog.Known precision trade-offs
The file already documents the
DATABASE_URLto Postgres trade-off. These fournew entries carry a comment in the same style:
Dbt— the signals prove the project uses dbt, not dbt Cloud. The sourceneeds dbt Cloud credentials.
TemporalIO— the signals also match a self-hosted cluster. The source wantsTemporal Cloud mTLS certificates.
Firebase— thefirebaseclient SDK also covers auth-only projects, whichhave no data to import.
Wordpress— recall is low, because PHPcomposer.jsonis not a manifest weread.
Two candidates were rejected.
PlanetScalePostgreshas no distinguishablefootprint, because those projects use
DATABASE_URL.Framerwould only matchthe Motion animation packages.
Ambiguous env keys use an exact match instead of a prefix:
RENDER_API_KEY,COURIER_AUTH_TOKEN,TALLY_API_KEY,LOB_API_KEY,DUB_API_KEY,FLY_API_TOKENand the three documentedTRIGGER_*keys. Amazon SES matchesAWS_SES_only, never a bareAWS_.Test plan
Covered by CI.
src/lib/warehouse-sources/__tests__/detect.test.tsgains:source.
@neondatabase/serverlessplusDATABASE_URLreports both Neon and Postgres.
framer-motionandmotiondetect nothing, and a loneTRIGGER_WORKFLOW,COURIER_TRACKING_URL,RENDER_MODEorTALLY_LEDGER_IDkey detects nothing.kindinSOURCE_DETECTORSis unique, and asecond guard that every entry has a label and at least one signal.
Full suite: 2047 passed, 0 failed. Prettier and ESLint are clean.
tsc --noEmitreports the same 30 pre-existing errors as
main, none in the files touched here.