@zen-agentchecks…zen/fix-redundant-trigger-error-logs-6bv0ns → master2 files · +0 −23review: @sohamganatrareview: @kaavee315review: @lingalarahul7review: @anshugarg15updated 1mo agoerrorToHTTPException already routes errors to logger.warn for 4xx and logger.error for 5xx via logByStatusCode. The explicit logger.error(...) calls in the trigger manage routes duplicate that — and worse, force-promote every TriggerInstance_TriggerInstanceGone (HTTP 410, logToError: false) to error level.
In the last 6 hours of production Apollo logs (Datadog cron poll), this anti-pattern produced ~6 spurious error-level entries:
Error getting trigger instance: ... TriggerInstance_TriggerInstanceGone ... statusCode:410Error managing trigger instance status: ... TriggerInstance_TriggerInstanceGone ... statusCode:410All of these are expected 410 Gone responses — the trigger or its connection chain was deleted — and logToError: false is explicitly set on the underlying error class. They should never have been at error level.
apps/apollo/src/pages/api/v3/trigger_instances/manage/[id].ts — DELETE + PATCH handlers: drop the 3 redundant logger.error calls before errorToHTTPException.apps/apollo/src/lib/triggers/manageTriggerInstance.ts — drop the 2 redundant logger.error calls in the service layer (their callers re-log the same error in the route handler anyway).Behavior preserved:
errorToHTTPException still logs at the appropriate level (warn for 4xx, error for 5xx) and emits the same structured payload via logByStatusCode.cd apps/apollo && doppler run -- pnpm check-types → passes (no diff in tsc output).cd apps/apollo && doppler run -- pnpm lint → only a pre-existing warning in composio_actions/utils/schemas.ts (unrelated).src/common/constants/error.ts:
BaseComposioHttpError._logToError() only logs at error level when this.logToError === true; TriggerInstance.TriggerInstanceGone defaults to logToError: false.errorToHTTPException calls logger.logByStatusCode(statusCode, payload) which routes >=500 → logger.error, <500 → logger.warn.Triggered by: Datadog Error Polling (cron-dd-errors) | Source: cron
Session: https://zen-api-production-4c98.up.railway.app/dashboard/#/chat/zen-cron-9b5bc382f339
Origin: cron-dd-errors / zen-cron-9b5bc382f339
Based on git blame analysis of 2 file(s):
| Contributor | Contribution | Files |
|---|---|---|
| lingalarahul7 | 46% | 2 |
| anshugarg15 |
| 22% |
| 1 |
| Himanshu Dixit | 19% | 1 |
| devin-ai-integration[bot] | 13% | 1 |
| acsrujan | 1% | 1 |
Recommend anshugarg15 and lingalarahul7. anshugarg15 made the most recent edit (2 weeks ago) to manageTriggerInstance.ts and will have fresh context on the change, while lingalarahul7 is a major contributor across both files (last active ~1 month ago) and can provide broader repository knowledge.
🤖 Based on git blame with recency weighting (recent edits count more).
:white_check_mark: All modified and coverable lines are covered by tests.
| Flag | Coverage Δ | |
|---|---|---|
| e2e-tests | 5.80% <ø> (+<0.01%) | :arrow_up: |
| self-hosted-tests | 5.61% <ø> (+<0.01%) | :arrow_up: |
| thermos-unit-tests | ? | |
| unit-tests | 58.75% <ø> (+<0.01%) | :arrow_up: |
Flags with carried forward coverage won't be shown. Click here to find out more.
| Files with missing lines | Coverage Δ | |
|---|---|---|
| ...s/apollo/src/lib/triggers/manageTriggerInstance.ts | 46.98% <ø> (+3.50%) | :arrow_up: |
| .../src/pages/api/v3/trigger_instances/manage/[id].ts | 0.00% <ø> (ø) |
... and 264 files with indirect coverage changes
