@zen-agentchecks…zen/quiet-trigger-4xx-logs-iytfke → master3 files · +5 −3review: @sohamganatrareview: @kaavee315review: @lingalarahul7review: @anshugarg15updated 4w agoThree call sites in the trigger instance flow were emitting logger.error() for failures that are typically client errors (4xx). In a 6-hour Datadog window of the apollo-logs index these accounted for ~30 of the 200 ERROR-level entries, polluting alerting on what are ordinary customer-facing 4xx responses:
apps/apollo/src/lib/triggers/manageTriggerInstance.ts — Error getting trigger instance: ... was logged at error level even when the inner result was TriggerInstance_TriggerInstanceGone (HTTP 410). The error class itself sets logToError: false to suppress its own debug log; the manual logger.error call here bypassed that flag.apps/apollo/src/pages/api/v3/trigger_instances/manage/[id].ts (DELETE handler) — same pattern.apps/apollo/src/lib/triggers/setupTriggerInstance.ts validateTriggerConfig — Invalid trigger config for {trigger}: ... was logged at error level for user-supplied invalid config (the route returns 400 TriggerInstance_ConfigInvalid). In production we saw this fire repeatedly for GOOGLEDOCS_* / GOOGLESHEETS_* / GOOGLESLIDES_* upserts where users submitted incomplete configs.DB_TRIGGER_INSTANCE_GET.byNanoId lookup sites, branch on triggerInstance.val.statusCode < 500 so 4xx logs at warn and only genuine server errors stay at error. BaseComposioHttpError.statusCode is already a typed required field on every Apollo error class.validateTriggerConfig, drop the level unconditionally to warn since that path can only return 400 ConfigInvalid to the caller.The log messages and structured fields are unchanged so existing dashboards / debugging workflows still work — only the severity changed.
doppler run -- pnpm with-env vitest run src/lib/triggers/setupTriggerInstance.test.ts — 5/5 passed (including the validateTriggerConfig failure-path tests that exercise the changed line).doppler run -- pnpm check-types from apps/apollo — clean (tsgo --noEmit, no errors).BaseComposioHttpError to confirm statusCode is a required typed field on every error subclass, so the conditional is safe across all return paths of DB_TRIGGER_INSTANCE_GET.byNanoId (TriggerInstanceGone 410, InternalServerError 500).Origin: cron-dd-errors / zen-cron-68aa84349d0e Triggered by: Cron: Datadog Error Polling cron-dd-errors | Source: unknown Session: https://zen-api-production-4c98.up.railway.app/dashboard/#/chat/zen-cron-68aa84349d0e
Based on git blame analysis of 3 file(s):
| Contributor | Contribution | Files |
|---|---|---|
| lingalarahul7 | 44% | 3 |
| anshugarg15 | 32% |
| 2 |
| Himanshu Dixit | 8% | 2 |
| Jayesh Sharma | 6% | 1 |
| devin-ai-integration[bot] | 5% | 2 |
Recommend: anshugarg15 and lingalarahul7.
🤖 Based on git blame with recency weighting (recent edits count more).
:x: Patch coverage is 20.00000% with 4 lines in your changes missing coverage. Please review.
| Files with missing lines | Patch % | Lines |
|---|---|---|
| ...s/apollo/src/lib/triggers/manageTriggerInstance.ts | 0.00% | 2 Missing :warning: |
| .../src/pages/api/v3/trigger_instances/manage/[id].ts | 0.00% | 2 Missing :warning: |
| Flag | Coverage Δ | |
|---|---|---|
| e2e-tests | 6.05% <0.00%> (-0.01%) | :arrow_down: |
| self-hosted-tests | 5.59% <0.00%> (-0.01%) | :arrow_down: |
| thermos-service-isolation-tests | ? | |
| thermos-unit-tests | ? | |
| unit-tests | 58.70% <20.00%> (+<0.01%) | :arrow_up: |
Flags with carried forward coverage won't be shown. Click here to find out more.
| Files with missing lines | Coverage Δ | |
|---|---|---|
| ...ps/apollo/src/lib/triggers/setupTriggerInstance.ts | 48.71% <100.00%> (ø) | |
| ...s/apollo/src/lib/triggers/manageTriggerInstance.ts | 43.01% <0.00%> (-0.47%) | :arrow_down: |
| .../src/pages/api/v3/trigger_instances/manage/[id].ts | 0.00% <0.00%> (ø) |
... and 268 files with indirect coverage changes
