feat: report devices appearing in a fleet

[simplesagar]

Note

Stacked PR — merge bottom-up. Each PR targets the one above it, so its Files tab shows only its own diff.

1. feat: add the growthsignals activity taxonomy and emitter #6057 — core taxonomy and emitter
2. feat: forward audited mutations to PostHog #6058 — audit stream to PostHog
3. feat: report signups as invited or organic #6059 — direct emits: signup source, org created, member joined
4. feat: report devices appearing in a fleet #6060 — devices 👈 this PR
5. feat: report agents new to an organization #6061 — agents

Merging #6057 retargets #6058 to main automatically, and so on down the stack.

GRW-66

Fourth of a five-PR stack. Targets #6059, review that first.

Summary

Emits device_first_seen when an MDM snapshot inserts a device the inventory has not held before.

Detecting that at all required a query change. UpsertMdmDevice returned the same row count on insert and on update, so a first sighting and a re-sighting were indistinguishable. It now returns (xmax = 0), which is true only on a freshly inserted row. The config-guard case, which previously surfaced as a zero row count, is now no row at all and maps to the same stale-sync outcome as before, so that behaviour is unchanged.

Two guards keep this from flooding the channel:

• A config's first successful sync is a backfill, not news. It inserts the whole existing fleet at once, so it reports nothing. last_poll_success_at is the signal, newly exposed on GetSyncTarget.
• Later syncs report at most ten devices. A fleet that doubles overnight is worth one glance at the dashboard, not hundreds of notifications. The devices are all in the inventory either way.

Reporting happens only after the snapshot is durable. Emitting inside the loop would announce devices for a run that later aborts as stale, and every abort path returns before the emit.

These activities are organization-scoped, because no MDM table carries a project id.

Motivation

Devices were the riskiest item on the ticket precisely because none of the three device ingest paths could tell that a row was new, and the bulk-sync shape meant a naive implementation would announce an entire fleet the first time an integration was connected.

Temporal actions/month: 0, scales with fixed. No schedules, workflows or activities are added; this rides the existing device-integration sync.

---

Summary by cubic

Emits device_first_seen when an MDM snapshot inserts a device the inventory hasn't held before, covering the devices scope of GRW-66. The upsert previously returned the same row count on insert and update, so a first sighting and a re-sighting were indistinguishable.

• UpsertMdmDevice now returns (xmax = 0), true only on a freshly inserted row; the config-guard case is now no row at all and maps to the same stale-sync outcome as before.
• Two guards prevent flooding: a config's first successful sync is a backfill and reports nothing (via last_poll_success_at, newly exposed on GetSyncTarget), and later syncs report at most ten devices.
• The device's assigned user travels as a device_owner_email property rather than the actor, so the sighting isn't attached to the owner's PostHog person.
• Reporting is at-most-once: rows committed before a later-page failure read as existing on retry, so the retry reports nothing.
• Reporting happens only after the snapshot is durable, so runs that later abort as stale announce nothing.
• These activities are organization-scoped because no MDM table carries a project id.
• No Temporal schedules, workflows, or activities are added; this rides the existing device-integration sync.
• The design spec drops the MCP settings destination; those events ride the firehose instead.

^{Written for commit 9392ab5. Summary will update on new commits.}

[linear-code]

GRW-66

[changeset-bot]

🦋 Changeset detected

Latest commit: 9392ab5

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
server	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[cubic-dev-ai]

Running ultrareview automatically — This changes the MDM upsert to rely on Postgres xmax to distinguish inserts from updates, and a subtle bug here could break stale-sync detection and merge stale inventory into new configs, risking data integrity.. I'll post findings when complete.

[cubic-dev-ai]

Ultrareview completed in 4m 51s

All reported issues were addressed across 8 files

<sub>Tip: instead of fixing issues one by one fix them all with cubic

Re-trigger cubic</sub>