fix(analytics): make comment collaboration readable in Workspace reporting - #6731
fix(analytics): make comment collaboration readable in Workspace reporting#6731open-design-crew[bot] wants to merge 1 commit into
Conversation
…rting
Two gaps made `project_comment_create_result` unusable for answering "who
comments on someone else's project".
`target_project_relation` reported `unknown` for ~2/3 of production comments.
Those were not failures: an unbound local project, or one in a personal
single-member workspace, has no second party to compare the author against.
They now report `not_applicable`, leaving `unknown` to mean only a shared
project whose owner genuinely failed to resolve. The owner lookup also no
longer swallows a thrown error into the same bucket as an absent owner.
Daemon events also carried no workspace group affiliation, so they were
missing from every workspace-scoped aggregation. The call site did set
`$groups` inline, but posthog-node rebuilds the payload as
`{ ...properties, $groups: groups }` and overwrote it with the unpassed
argument. Group affiliation is now lifted to that argument for every daemon
capture, so call sites can keep the inline form the web SDK uses.
补充：按客户端版本拆过之后，收益预期要修正开 PR 之后又按 "未知"其实是两批完全不同的东西混在一起（近 14 天）：
按天看更清楚，0.18.1 从 8/07 起接管流量：
两个结论：
所以准确的预期是：光等用户升级，"未知"会从 ~35% 掉到 ~22% 然后永远卡住；本 PR 解决的是卡住的这 22%。 对验收的影响（重要）发版后回看数据时必须按 |
lefarcen
added
size/L
lefarcen
added
the
skip-validation
nettee
left a comment
nettee
left a comment
There was a problem hiding this comment.
I found one blocking analytics-classification issue: the new relation helper still classifies normal bound personal-project comments as self/other, so the PR's intended not_applicable bucket is not reached for that production path. The focused daemon tests and typechecks pass, but they do not cover a populated personal binding.
🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.
| workspaceContext: WorkspaceCollabContext | null; | ||
| ownerLookupFailed: boolean; | ||
| }): TrackingProjectRelationOrNotApplicable { | ||
| if (input.authorMemberId && input.ownerMemberId) { |
There was a problem hiding this comment.
This comparison runs before the personal-workspace check, but the route seeds ownerMemberId from localBinding.createdByWorkspaceMemberId before calling this helper (the binding is populated for projects created in a personal workspace). As a result, a normal personal-project comment has both IDs and is emitted as self or other; not_applicable is only returned when the owner happens to be null. That leaves the main personal-traffic bucket misclassified and defeats the stated goal of separating single-member projects from real resolution failures. Check the workspace type before comparing IDs (or only use the binding owner for team contexts), and add a regression with workspaceType: 'personal' plus a populated owner/binding ID.
🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.
|
Quick triage catch-up: the blocking item on this head is already covered by @nettee's review, so the next step is to fix that personal-workspace classification path and add the regression they called out. Once there's a new push, we can re-check from there. |
3 participants
Why
Workspace 改版后我们想回答一个问题：团队里到底有多少人在别人的项目上评论？ 这是协作是否真的发生的核心信号。
看板搭起来之后发现这个问题答不了。评论创建事件有两个缺口：
排查下来，两个缺口都不是"漏埋点"，而是两处判断本身就不成立。
What users will see
用户侧没有任何变化 —— 不改界面、不改行为，只改我们自己看到的数据。
对看数据的人来说变化是：
另外顺手确认了一件事："几乎没人评论别人的项目"是真的，不是被"未知"藏起来了。 我按数据把"未知"拆开看过，里面一条团队项目的评论都没有 —— 全部是个人空间和本地项目。真实的跨人评论近 14 天只有 15 条。所以这个修复不会让"评论他人项目"的数字变多，它的价值是让这张图从今往后可信。
Surface area
packages/contracts里评论事件的分类取值新增not_applicable看板不需要改：对应的图用的是开放式拆分，新分类会自动出现。
Bug fix verification
apps/daemon/tests/project-comment-permissions.test.tsapps/daemon/tests/analytics-env.test.tsreports a project with no owner to compare against as not_applicabletreats a personal workspace as having no second partysends $groups written inline by a call site as posthog-node group affiliationomits group affiliation when a call site sends no usable $groups两处根因
其一，分类逻辑把"没有答案"和"算不出来"当成了同一回事。
原来的写法是：作者和项目归属两边只要有一边取不到，就记"未知"。但个人空间只有一个成员、本地项目连工作区都没有 —— 这两种情况下"归属"根本不存在，不是查失败。占比最大的那块"未知"就是这么来的。
其二，工作区归属被 PostHog 的 SDK 悄悄丢掉了。
调用处其实是写了工作区归属的，写法也和网页端一致，所以看代码完全看不出问题。但 posthog-node 内部会用它自己的参数重新拼一遍事件，把写在属性里的那份无条件覆盖掉 —— 而我们从来没传过那个参数，于是每次都被覆盖成空。现在把工作区归属提到 SDK 要求的位置上，所有 daemon 事件都一起修好，不只是评论这一个 —— 后面任何服务端事件都会踩同一个坑。
Validation
pnpm guard— 通过pnpm typecheck— 通过pnpm --filter @open-design/daemon typecheck— 通过project-comment-permissions/analytics-env/workspace-project-analytics/attribution/project-comment-workspace-gateAdjacent issues（本次不做）
comment_level目前写死top_level，而契约里声明了top_level | reply。核对过：评论在产品上是画布批注，「回复」走的是编辑同一条记录、不产生新事件，所以reply是一个产品产不出来的死值。这是产品决策不是 bug —— 要么上线真正的讨论串，要么把这个维度删掉，等 Eli 定。