You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Events could not become people. Nothing identified an install — no distinct_id,
no device id, nothing persisted — so 400 pushes could have been 4 users or 40,
and retention and funnels were unanswerable. This is the question
quiltsync-telemetry-host closed on as "blocked on whether one may be attached
at all"; the answer is that counting installs needs nothing about a user.
A random UUID, minted on first run and persisted beside the app's own data,
derived from nothing. Not an email hash: that is reversible for a customer set
already known, so it would carry the obligations of personal data while feeling
as though it did not — and it counts accounts, not installs, being absent
before the first login, which is exactly where the onboarding funnel starts.
Reaches all three sinks so they can be read together: the analytics
distinct_id, the crash reporter's user.id, and a field in the diagnostic
export. A crash now leads to that install's event stream leads to the archive
its user emailed in.
Two design points worth keeping:
- The identity rides the crash client's *event hook*, beside the host tag, not
a scope. It is fixed for the process, so this is not about staleness — a
scope carrying it would still reach only threads that snapshotted after it
was set. One mechanism, both facts.
- `wire_payload` is separate from `event_payload` so the two stay honest about
whose fact each property is: the payload belongs to the *event* and is pinned
by its own tests, while distinct_id belongs to the *install* and to nothing
the vocabulary describes. A payloadless event still gets a properties object,
because it still has an identity — and app launch, the head of every funnel,
is exactly that case.
Failure semantics, which are the whole reason this is not three lines:
- Cannot persist -> report no identity, never an unpersisted one. An id that is
not on disk is a *new* id next launch, inflating the install count precisely
when disks are unhappy.
- Read fails for any reason other than absence -> report none, and do not mint
a replacement, which would discard a real install's history to satisfy one run.
- Written atomically (temp + rename), so an interrupted write cannot leave a
truncated value that reads as a different install forever.
- No identity means an *unattributed* event, never a dropped one — anything
else loses the events of the machines having trouble.
Locally verifiable via the dry run, which shows the identity — the first unit
the rig from #820 actually pays for.
just lint 0, cargo fmt --check 0, 300 quilt-sync tests, workspace green.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments