fix(quests): track shared post clicks from post page

[rebelchris]

Summary

• Adds the shared post click mutation client and hook for attributed quest progress.
• Mounts the hook on the post page so shared daily.dev post links can credit the referring user.
• Adds focused coverage for post-page firing and hook eligibility behavior.

Key decisions

• Fires only for post-share campaigns (share_post and share_slack) with both userid and a resolved post id.
• Skips self-clicks, runs for authenticated and anonymous visitors, and guards against repeat sends during rerenders.
• Swallows client-side tracking errors so the clicker's page is never disrupted.

Verification

• NODE_ENV=test pnpm exec jest packages/shared/src/hooks/useShareLinkClick.spec.tsx --runInBand
• NODE_ENV=test pnpm exec jest packages/webapp/__tests__/PostPage.tsx --runInBand
• NODE_ENV=test pnpm exec eslint packages/shared/src/hooks/useShareLinkClick.ts packages/shared/src/hooks/useShareLinkClick.spec.tsx packages/shared/src/graphql/quests.ts packages/webapp/pages/posts/[id]/index.tsx packages/webapp/__tests__/PostPage.tsx
• NODE_ENV=test pnpm run typecheck:strict:changed

Closes ENG-1783

---

Created by Huginn 🐦‍⬛

Preview domain

https://eng-1783-feedback-bug-report-use.preview.app.daily.dev

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
daily-webapp	Ready	Preview	Sep 11, 2026 9:33am UTC

[rebelchris]

Reviewed together with dailydotdev/daily-api#4263.

Blocking (cross-repo, tracked on the API PR): attribution here is just the cid and userid query params, and the API mutation is unauthenticated and trusts them as-is. So the "click" a Cores-paying quest counts is something anyone can produce by opening …/posts/<id>?cid=share_post&userid=<any user> — no share ever needed — and the server's only per-clicker dedup is the tracking cookie, which the same visitor can drop on each load. The self-click skip here (referringUserId !== user?.id) also does nothing once the sharer is logged out. I left the detail and the suggested fixes on daily-api#4263; this PR is fine to land only once that side stops trusting raw params. Three smaller notes inline.

Reviewed by AI.

[rebelchris]

Non-blocking: enabled has no caller — the only mount passes postId alone — and no test covers it. Please drop it until a surface actually needs to switch the hook off.

Reviewed by AI.

[rebelchris]

Non-blocking: shouldTrackShareLinkClick is exported and unit-tested, but the hook re-implements the same four conditions inline instead of calling it. The two copies can drift, and the tests would then be asserting a predicate the hook does not use. Call shouldTrackShareLinkClick({ campaign, referringUserId, postId, userId: user?.id }) here and keep enabled/isAuthReady as the only extra guards.

Reviewed by AI.

[rebelchris]

Non-blocking: trackedKeysRef only lives for the mount, so a refresh or a re-entry to the same shared post fires the mutation again. Server-side that is deduped per UTC day, but it is charged against the caller's 20/60s rate-limit bucket on the API, so a visitor reloading a shared link a few times can exhaust their own budget and have a later genuine click rejected. Persisting the click key (sessionStorage) would keep the retry-free behaviour across mounts.

Reviewed by AI.