claim db worker: update posthog and env vars#79
Merged
aidankmcalister merged 2 commits intomainfrom Mar 2, 2026
Merged
Conversation
aidankmcalister
requested review from
AmanVarshney01,
ankur-arch and
carlagn
WalkthroughRefactors analytics infrastructure by replacing direct PostHog API calls with centralized sendAnalyticsEvent functions across server and client implementations. Updates environment variables from POSTHOG_API_HOST to POSTHOG_PROXY_HOST and replaces PostHogProvider with PageViewTracker component for page tracking. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
|
✅ Preview CLIs & Workers are live! Test the CLIs locally under tag npx create-db@pr79
npx create-pg@pr79
npx create-postgres@pr79Worker URLs
|
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
claim-db-worker | 831a53a | Commit Preview URL Branch Preview URL |
Feb 27 2026, 05:58 PM |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
claim-db-worker/__tests__/callback-api.test.ts (1)
108-114:⚠️ Potential issue | 🟠 MajorTest assertion does not match the new analytics endpoint.
The pipeline failure indicates this test expects
posthog.comin the fetch URL, but the implementation now sends analytics toPOSTHOG_PROXY_HOST(mocked ashttps://proxyhog.prisma-data.neton line 12). The assertion needs to match the proxy host.🐛 Proposed fix
expect(mockFetch).toHaveBeenCalledWith( - expect.stringContaining("posthog.com"), + expect.stringContaining("proxyhog.prisma-data.net"), expect.objectContaining({ method: "POST", body: expect.stringContaining("create_db:claim_successful"), }) );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@claim-db-worker/__tests__/callback-api.test.ts` around lines 108 - 114, The test assertion in callback-api.test.ts is still expecting "posthog.com" (see expect.stringContaining("posthog.com")) but the code now sends analytics to the POSTHOG_PROXY_HOST (mocked as "https://proxyhog.prisma-data.net"); update the expect.toHaveBeenCalledWith call to check for the proxy host string (e.g. expect.stringContaining(process.env.POSTHOG_PROXY_HOST or the mocked "https://proxyhog.prisma-data.net")) and keep the existing objectContaining assertions (method/body) intact so mockFetch is asserted against the correct analytics endpoint.
🧹 Nitpick comments (2)
claim-db-worker/components/PostHogProvider.tsx (1)
5-12: Consider renaming the component for clarity.The component no longer provides a PostHog context; it simply renders
PageViewTrackeralongside children. The namePostHogProvideris now misleading. Consider renaming to something likeAnalyticsWrapperorAnalyticsProviderin a follow-up to better reflect its current purpose.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@claim-db-worker/components/PostHogProvider.tsx` around lines 5 - 12, The component PostHogProvider no longer provides a PostHog context and the name is misleading; rename the exported component PostHogProvider to a clearer name (e.g., AnalyticsWrapper or AnalyticsProvider) and update all references/usages accordingly so that the function Component PostHogProvider (which renders PageViewTracker and children) is renamed and exported under the new name, and any imports/usages across the codebase that reference PostHogProvider are updated to the new identifier.claim-db-worker/app/api/analytics/route.ts (1)
48-50: Consider distinguishing JSON parse errors from analytics failures.The catch block handles both JSON parsing errors (client error) and potential analytics failures. Currently, both return a 500 status, but invalid JSON from the client would more accurately be a 400 Bad Request.
🔧 Optional: More precise error handling
- try { - const body = (await request.json()) as { + let body: { event?: string; properties?: Record<string, unknown> }; + try { + body = await request.json(); + } catch { + return NextResponse.json( + { error: "Invalid JSON body" }, + { status: 400 } + ); + } + + try { + const body = body as { event?: string; properties?: Record<string, unknown>; };Alternatively, a simpler approach keeping the current structure:
} catch (error) { - console.error("Failed to send PostHog event:", error); - return NextResponse.json({ error: "Analytics failed" }, { status: 500 }); + if (error instanceof SyntaxError) { + return NextResponse.json({ error: "Invalid JSON body" }, { status: 400 }); + } + console.error("Failed to send PostHog event:", error); + return NextResponse.json({ error: "Analytics failed" }, { status: 500 }); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@claim-db-worker/app/api/analytics/route.ts` around lines 48 - 50, The catch block in the route handler currently treats JSON parse errors and analytics failures the same; update the catch to detect client-side JSON parse errors (e.g., error.name === 'SyntaxError' or error instanceof SyntaxError) and return NextResponse.json({ error: "Invalid JSON" }, { status: 400 }) for those, otherwise keep logging (console.error("Failed to send PostHog event:", error)) and return the 500 response; adjust the existing catch in route.ts around the PostHog/send logic and use NextResponse.json for both branches.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@claim-db-worker/__tests__/callback-api.test.ts`:
- Around line 108-114: The test assertion in callback-api.test.ts is still
expecting "posthog.com" (see expect.stringContaining("posthog.com")) but the
code now sends analytics to the POSTHOG_PROXY_HOST (mocked as
"https://proxyhog.prisma-data.net"); update the expect.toHaveBeenCalledWith call
to check for the proxy host string (e.g.
expect.stringContaining(process.env.POSTHOG_PROXY_HOST or the mocked
"https://proxyhog.prisma-data.net")) and keep the existing objectContaining
assertions (method/body) intact so mockFetch is asserted against the correct
analytics endpoint.
---
Nitpick comments:
In `@claim-db-worker/app/api/analytics/route.ts`:
- Around line 48-50: The catch block in the route handler currently treats JSON
parse errors and analytics failures the same; update the catch to detect
client-side JSON parse errors (e.g., error.name === 'SyntaxError' or error
instanceof SyntaxError) and return NextResponse.json({ error: "Invalid JSON" },
{ status: 400 }) for those, otherwise keep logging (console.error("Failed to
send PostHog event:", error)) and return the 500 response; adjust the existing
catch in route.ts around the PostHog/send logic and use NextResponse.json for
both branches.
In `@claim-db-worker/components/PostHogProvider.tsx`:
- Around line 5-12: The component PostHogProvider no longer provides a PostHog
context and the name is misleading; rename the exported component
PostHogProvider to a clearer name (e.g., AnalyticsWrapper or AnalyticsProvider)
and update all references/usages accordingly so that the function Component
PostHogProvider (which renders PageViewTracker and children) is renamed and
exported under the new name, and any imports/usages across the codebase that
reference PostHogProvider are updated to the new identifier.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
claim-db-worker/__tests__/callback-api.test.tsclaim-db-worker/app/api/analytics/route.tsclaim-db-worker/app/api/auth/callback/route.tsclaim-db-worker/app/api/claim/route.tsclaim-db-worker/components/PageViewTracker.tsxclaim-db-worker/components/PostHogProvider.tsxclaim-db-worker/lib/analytics-client.tsclaim-db-worker/lib/analytics.tsclaim-db-worker/lib/env.ts
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR goes hand in hand with a message I have sent to @ankur-arch around updating the secrets in cloudflare. That must be done prior to merging
Summary by CodeRabbit
Release Notes
New Features
Improvements
Tests