feat(features): offer server-side HTTP log capture on Cloudflare Workers projects - #1114
feat(features): offer server-side HTTP log capture on Cloudflare Workers projects#1114lricoy wants to merge 2 commits into
Conversation
…ers projects Detect Cloudflare Workers projects (wrangler config or Cloudflare packages) and surface an opt-in tip that queues an additional-feature prompt guiding the agent to set up $http_log capture for bot analytics, mirroring the LLM observability opt-in. Generated-By: PostHog Desktop Task-Id: 9023dadc-319f-42e8-a662-7990f1aff585
🧙 Wizard CIRun the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands: Test all apps:
Test all apps in a directory:
Test an individual app:
Show more apps
Results will be posted here when complete. |
项目 without a wrangler config but with a root middleware file (Next.js convention) also get the server-log opt-in, and the tip copy no longer claims Cloudflare specifically. Generated-By: PostHog Desktop Task-Id: 9023dadc-319f-42e8-a662-7990f1aff585
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: af80cec8c4
ℹ️ 关于 Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| /** Agent prompts for each additional feature, injected via the stop hook */ | ||
| export const ADDITIONAL_FEATURE_PROMPTS: Record<AdditionalFeature, string> = { | ||
| [AdditionalFeature.LLM]: `Now integrate AI observability with PostHog. Use the PostHog MCP server to find the appropriate AI observability skill, install it, and follow its workflow. PostHog basics are already installed. Update the setup report markdown file when complete with additions from this task. `, | ||
| [AdditionalFeature.HttpLog]: `Now integrate server-side HTTP log capture with PostHog so bots, crawlers, and AI agents show up in web analytics. 关注 https://posthog.com/docs/web-analytics/sending-http-logs: send one $http_log event per request to the capture API, with $raw_user_agent, $current_url, $ip, and $process_person_profile set to false, using a hashed per-client distinct ID. Prefer the platform's native hook (a Cloudflare Worker on Workers projects, otherwise server middleware), keep it off the request path, and skip static asset requests. PostHog basics are already installed. Update the setup report markdown file when complete with additions from this task. `, |
There was a problem hiding this comment.
This embeds the complete product-specific HTTP-log integration workflow in wizard-session.ts, so changes to the payload requirements or supported platforms require a wizard release and can drift from the documentation. Put this workflow in a context-mill markdown skill and have the queued prompt discover and install that skill, as the existing LLM feature does.
AGENTS.md reference: AGENTS.md:L16-L17
Useful? React with 👍 / 👎.
| store.session.discoveredFeatures.includes(DiscoveredFeature.HttpLog), | ||
| toggle: { | ||
| key: 'b', | ||
| feature: AdditionalFeature.HttpLog, |
There was a problem hiding this comment.
When the wizard-orchestrator flag routes posthog-integration through the orchestrator, pressing B displays “queued next,” but orchestrator-runner.ts passes additionalFeatureQueue: [] to both the seed and every task (lines 659 and 935). Consequently the new prompt is never injected for that experiment cohort even though the UI accepted the opt-in; thread the session queue through that sequence or suppress the toggle when the selected sequence cannot consume it.
Useful? React with 👍 / 👎.
| [...WRANGLER_CONFIG_FILES, ...MIDDLEWARE_FILES].some( | ||
| (file) => safeRead(installDir, file) !== null, | ||
| ) |
There was a problem hiding this comment.
The new Wrangler and middleware file checks execute only after package.json has been read and parsed, because discoverNodeFeatures returns at lines 88 and 97 otherwise. A config-only Wrangler project, a non-Node Worker project, or a project with a temporarily malformed manifest therefore never gets HttpLog despite having one of the advertised marker files; perform these file checks independently of package-manifest parsing.
Useful? React with 👍 / 👎.
Problem
Bots, crawlers, and AI agents rarely run JavaScript, so a wizard-installed JS SDK never sees them. Web analytics bot analytics needs server-side $http_log events, and the wizard has no way to offer that setup even on projects where it is a one-file change.
Changes
wrangler,@cloudflare/workers-types, framework adapters), or a root middleware file (Next.js convention).b): "PostHog can show you bot and AI crawler traffic". Opting in queues an additional-feature prompt, exactly like the existing LLM observability opt-in.$raw_user_agent/$current_url/$ip, anonymous person processing, hashed per-client distinct ID, off the request path, skip static assets.Test plan
features.test.ts: the HttpLog feature is discovered from awranglerdependency, awrangler.tomlconfig file, and a rootmiddleware.ts. Suite passes locally (15/15).pnpm typecheckfails only on pre-existing errors insrc/utils/bounded-fs.ts, untouched here; eslint reports 0 errors.LLM context
Authored with Claude Code in a PostHog Desktop cloud task, mirroring the AdditionalFeature.LLM opt-in flow. Part of a wider $http_log adoption effort: source templates in PostHog/posthog#85969, docs in PostHog/posthog.com#19588.
Created with PostHog Desktop