Skip to content

fix(logs): log the webhook poll id and emitted event id under their own names - #9747

Merged
waleedlatif1 merged 1 commit into
stagingfrom
fix/poll-log-ids
Nov 6, 2026
Merged

waleedlatif1 merged 1 commit into
stagingfrom
fix/poll-log-ids

Conversation

@waleedlatif1

Copy link
Copy Markdown
Collaborator

Summary

  • Found in the v0.9.45 release review: webhook polls and Sim events logged their own generated ids as requestId. The logger lets the request context own that field, and both run inside the poll route's request context, so the poll id and the per-event id never reached a log line
  • The poll orchestrator names its per-poll id pollId and binds it on the handler logger with webhookId, so every handler line carries it
  • Drops the per-line { requestId } fields from all eight polling handlers and skipAdmissionRefusedPoll, plus the helper params and the HubSpot filter-limit error prefix that only fed them
  • The Sim event emitter logs its per-event id as dispatchId
  • The ids passed downstream are unchanged: each poll still passes its id as requestId to processPolledWebhookEvent and OAuth refresh, and each emitted event still passes its own, so execution request ids and idempotency keys stay unique per poll and per event
  • add-trigger skill: polling handlers log through ctx.logger and never add { requestId }

Type of Change

  • Bug fix

Testing

  • Existing polling tests (gmail, google-calendar, hubspot, imap, rss, orchestrator, utils) and workspace-events/emitter.test.ts pass
  • biome, check:source-conventions, check:comment-hygiene, check:test-patterns, check:utils; type-check via the pre-push hook

Checklist

  • Code follows project style guidelines
  • Self-reviewed my changes
  • Tests added/updated and passing (new tests pass the test-audit authoring gate)
  • No new warnings introduced
  • I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

…wn names

Webhook polls and Sim events logged their own generated ids as requestId, which the poll route's request context overwrites, so the ids never reached a log line. The orchestrator now binds each poll's id on the handler logger as pollId, handlers drop their per-line requestId fields, and the event emitter logs its per-event id as dispatchId. The ids passed downstream as each execution's request id are unchanged.
@vercel

vercel Bot commented Nov 6, 2026

Copy link
Copy Markdown

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

Project Deployment Actions Updated
docs Building Building Preview Nov 6, 2026 7:45pm UTC

Request Review

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 13 files

Confidence score: 5/5

  • Automated review surfaced no issues in the provided summaries.
  • No files require special attention.

Turn on auto-fix | Re-trigger cubic

@greptile-apps

greptile-apps Bot commented Nov 6, 2026 •

Copy link
Copy Markdown
Contributor

RetriggerView in GreptileConfidence Score: 5/5

[Medium impact] The PR appears safe to merge; log IDs stay distinct and downstream execution IDs are preserved.

Summary

This PR separates generated poll and event IDs from the HTTP request ID in logs.

  • Webhook polling logs identify each poll with its own ID.
  • Sim event failure logs identify each event with its own ID.

No actionable issues were found. Review checks were source-based; no tests were run.

Reviews (1) · Last reviewed commit: "fix(logs): log the webhook poll id and e..." · Reviewed by Greptile

This branch was successfully deployed

1 active deployment
Preview — 2f515612 Deployed Nov 6, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant