Skip to content

oncetask: log handler errors from SafeExecute - #20

Merged
anish749 merged 1 commit into
mainfrom
oncetask/log-handler-errors
May 17, 2026
Merged

oncetask: log handler errors from SafeExecute#20
anish749 merged 1 commit into
mainfrom
oncetask/log-handler-errors

Conversation

@anish749

Copy link
Copy Markdown
Owner

Problem

When a task handler returns an error, oncetask records the error in the task's errors array in Firestore but does not emit a log line. Handler-error visibility in Cloud Logging therefore depends on each handler logging the error itself. The two completion-adjacent log lines (once_task_firestore.go:292, :319) only fire when the Firestore persistence of the completion itself fails — a different, rarer event — and they use m.ctx, so they don't pick up taskId/resourceKey (or any caller-attached fields) via ContextHandler.

Solution

Emit a single slog.ErrorContext(ctx, "Handler returned error", "error", err) inside SafeExecute when the wrapped function returns an error. SafeExecute is the chokepoint for all three production handler paths (cancellation, single-task, resource-batch). The ctx passed in already carries taskId/resourceKey via withTaskContext / withSingleTaskContext / withResourceKeyTaskContext, so ContextHandler (oncetask/context_logger.go) auto-injects them and any caller-attached fields ride along.

Context

  • Recurrence-task bookkeeping (filterAndSpawnOccurrences) doesn't invoke user handlers and already logs its own errors.
  • The "claimed multiple tasks" invariant check at once_task_firestore.go:307-308 is an oncetask-internal bug and already logs itself.
  • Panic recovery in SafeExecute continues to log at Error with the same per-task ctx.

@anish749
anish749 merged commit 89be069 into main May 17, 2026
4 checks passed
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