Comfy-Org / Comfy-Org/Comfy-Desktop

Desktop->browser handoff telemetry needs a join key, or #1358/#14457 still cannot produce a rate

Open
#1,445 1 comment 0 reactions 1 assignee Claimed by @benceruleanlu View on GitHub
Dominant language
TypeScript
Stars
458
Forks
59
Avg merge
22h 18m
Merged PRs (30d)
45

Description

#1358 (Desktop) and Comfy-Org/ComfyUI_frontend#14457 (frontend) add events on both sides of the Desktop -> browser handoff. As drafted they will not produce a usable rate, so the gap they were written to close stays open.

## Problem

The arrival event carries no properties, and nothing correlates the two halves. So the handoff count and the arrival count cannot be divided by each other: there is no way to tell whether a given arrival corresponds to a given handoff, and the two numbers come from different populations (one Desktop-side via `posthog-node`, one browser-side via `web`).

We would land two events and still not be able to answer the actual question, which is what fraction of browsers that Desktop opens ever arrive at the redemption page.

## Why it matters

Today 41% of people who start a Desktop sign-in end up signed in nowhere, and we cannot subdivide that number at all. There is no event of any kind between "Desktop called `openExternal`" and "the code was redeemed", so a browser that never opened is indistinguishable from a user who walked away, which is indistinguishable from a redeem that failed silently.

That black box is why the 8 August regression ran for two weeks without anyone being able to localise it from telemetry alone.

## Suggested fix

Either:

1. Thread an attempt id through both sides. Desktop generates it at code creation, includes it on `sign_in_started` and in the URL it opens, and the frontend echoes it on the arrival event. Straightforward but requires both PRs to move together.
2. Or emit arrival server-side from the redeem endpoint, which already receives the installation id at code creation and can tie the two together without a frontend change at all.

Option 2 is less coupling and less client code, and it also survives the user closing the tab before any browser-side event flushes. Worth considering before landing the two PRs as drafted.

Whichever is chosen, the acceptance criterion is that we can compute "browsers opened -> browsers arrived -> codes redeemed" as three numbers over the same population.

## Related

- #1358 Make Desktop browser handoff observable
- Comfy-Org/ComfyUI_frontend#14457 Track Desktop login browser arrival

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.