@sarahsimionescuchecks…claude/fervent-dhawan-fd8184 → master5 files · +84 −2review: @rohanprabhureview: @sohamganatrareview: @sarthakreview: @acsrujanreview: @kaavee315review: @anshugarg15updated 1d agoRefs SUP-449, SUP-451.
The dashboard log-detail view currently reads encrypted payload columns straight from ClickHouse and shows iv:cipher:tag blobs. This PR extends Apollo's decrypt-on-read single-trigger-log endpoint so the dashboard can call the API instead (dashboard PR: https://github.com/ComposioHQ/dashboard/pull/775):
TriggerLogSchema.meta gains optional webhookEventId (webhook request id), triggerInstanceId, triggerType, triggerConfig, processingError, webhookDeliveryStatus, sdkDeliveryStatus, cliDeliveryStatus — populated in both ClickHouse and Postgres single-log backends.Encryption keys stay solely in Apollo; decryption is the endpoint's existing just-in-time safeDecrypt behind project-scoped authZ — no new crypto logic. Payloads are returned as stored (no key scrubbing), matching the previous behavior of these endpoints; sensitive-value scrubbing is deferred pending a team decision. List endpoints unchanged.
pnpm check-types, pnpm lint (0 errors), logger suite 32/32, OpenAPI regen clean.🤖 Generated with Claude Code
Dashboard counterpart: https://github.com/ComposioHQ/dashboard/pull/775 — merge/deploy this Apollo PR first (the dashboard reads the new meta fields).
Tool execution logs section on dashboard doesn't show the request and response of the tool call
Logs filtering has some issues, please check the slack thread here
The trigger logs currently shown on the dashboard are encrypted - we need to fix this by decrypting them before displaying
Closing my earlier finding: commit ceb69fde reverts all credential-header redaction from the trigger log read paths, so the list-vs-single-log inconsistency I flagged no longer exists.
For the record, the underlying concern (decrypted webhook provider payloads — including inbound Authorization, x-api-key, and similar headers — are returned unredacted by both the list and single-log endpoints) is still present, but it is pre-existing behaviour that predates this PR, so it's out of scope here. Worth tracking as a follow-up if the redaction work is picked up again.