Scope progress loggers to a workflow run and phase #103

New Issue

2026-10-05T12:50:13Z

eleith commented

2026-10-05 12:50:13 +00:00

Problem

The cached worker context contains one PhaseLogger. runProgressPhase mutates its activePhase and line counter on entry and clears them on exit. Overlapping workflows can therefore redirect each other's logs, reset numbering, or clear the destination while another phase is still running. Publish exclusion alone would not fix overlap with previews or other workflows.

Scope / acceptance

Bind logging to a run/phase for that execution rather than mutating process-global routing state.
Pass the scoped logger through existing step dependencies, including rclone/subprocess logging; avoid leaving those services bound to the old shared phase logger.
Preserve existing progress ordering/resume behavior and the public logger interface where practical.
Add a coordinated overlap regression showing logs stay with the correct job/phase before and after one phase finishes or fails.
Retain safe diagnostic boundaries; do not broaden logging of provider input, credentials, or raw errors. A wholesale Pino migration or general observability framework is out of scope.

Sources

Found through static inspection during the When comparison for #78. No concurrent-workflow reproduction was run during research. Can share explicit service ownership groundwork, but deserves its own focused change.

## Problem The cached worker context contains one `PhaseLogger`. `runProgressPhase` mutates its `activePhase` and line counter on entry and clears them on exit. Overlapping workflows can therefore redirect each other's logs, reset numbering, or clear the destination while another phase is still running. Publish exclusion alone would not fix overlap with previews or other workflows. ## Scope / acceptance - Bind logging to a run/phase for that execution rather than mutating process-global routing state. - Pass the scoped logger through existing step dependencies, including rclone/subprocess logging; avoid leaving those services bound to the old shared phase logger. - Preserve existing progress ordering/resume behavior and the public logger interface where practical. - Add a coordinated overlap regression showing logs stay with the correct job/phase before and after one phase finishes or fails. - Retain safe diagnostic boundaries; do not broaden logging of provider input, credentials, or raw errors. A wholesale Pino migration or general observability framework is out of scope. ## Sources - [`packages/web/worker/src/core/phase-logger.ts`](https://git.eleith.com/eleith/luzzle/src/branch/main/packages/web/worker/src/core/phase-logger.ts) - [`packages/web/worker/src/core/run-progress-phase.ts`](https://git.eleith.com/eleith/luzzle/src/branch/main/packages/web/worker/src/core/run-progress-phase.ts) - [`packages/web/worker/src/services/context.ts`](https://git.eleith.com/eleith/luzzle/src/branch/main/packages/web/worker/src/services/context.ts) - [`packages/web/worker/src/services/rclone.ts`](https://git.eleith.com/eleith/luzzle/src/branch/main/packages/web/worker/src/services/rclone.ts) Found through static inspection during the When comparison for #78. No concurrent-workflow reproduction was run during research. Can share explicit service ownership groundwork, but deserves its own focused change.

eleith added the bug label 2026-10-05 12:50:13 +00:00

eleith referenced this issue from a commit

2026-10-06 03:48:42 +00:00

[merge] land scoped progress logging (#103)

eleith closed this issue

2026-10-06 03:49:56 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: eleith/luzzle#103