Overview

The file pkg/cli/logs_orchestrator.go has grown to 1284 lines, making it difficult to maintain and test. It mixes orchestration logic, filter logic, type definitions, output rendering, and stdin-based processing into a single file. A significant portion of the run-filter and ProcessedRun-build logic is duplicated between DownloadWorkflowLogs and DownloadWorkflowLogsFromStdin.

Current State

• File: pkg/cli/logs_orchestrator.go
• Size: 1284 lines
• Test Coverage: pkg/cli/logs_orchestrator_test.go — 451 lines (~35% test-to-source ratio)
• Complexity: Two large public functions share nearly identical run-filter blocks (~150 lines each), plus a 600-line main loop in DownloadWorkflowLogs

Refactoring Strategy

Proposed File Splits

1. logs_orchestrator_types.go

   • Types: LogsDownloadOptions, StdinLogsOptions, continuationOptions, renderLogsOutputOptions
   • Responsibility: Pure type declarations with no logic
   • Estimated LOC: ~80

2. logs_orchestrator_filters.go

   • Functions: matchEngineFilter, applyRunFilters (new — deduplicate filter logic), buildProcessedRun (new — deduplicate ProcessedRun construction)
   • Responsibility: Decide whether a downloaded run should be included in results
   • Estimated LOC: ~180

3. logs_orchestrator_render.go

   • Functions: renderLogsOutput, renderLogsArtifactHint
   • Responsibility: Transform []ProcessedRun → console/JSON/markdown/TSV/pretty output
   • Estimated LOC: ~160

4. logs_orchestrator_stdin.go

   • Functions: DownloadWorkflowLogsFromStdin
   • Responsibility: Stdin-driven run discovery and processing path
   • Estimated LOC: ~180 (after duplication is extracted)

5. logs_orchestrator.go (trimmed)

   • Functions: DownloadWorkflowLogs, pagination helpers (shouldStopPagination, selectPaginationCursorDate, buildContinuationIfNeeded), small utilities (isDeadlineExceeded, applyMetricsTurnsToRun, noRunsMessage, parseFilterDate, getMaxConcurrentDownloads)
   • Responsibility: Primary entry point, pagination loop
   • Estimated LOC: ~500

Shared Utilities to Extract

• applyRunFilters(result DownloadResult, opts runFilterOpts, verbose bool) (skip bool) — replaces the repeated engine / staged / firewall / safe-output / DIFC filter blocks
• buildProcessedRun(result DownloadResult) ProcessedRun — replaces the repeated ProcessedRun{...} struct literal construction

Interface Abstractions

Consider a runProcessor interface (or simple functional type) to unify the two download paths and reduce future drift between them.

Implementation Guidelines

1. Preserve Behavior: Ensure all existing functionality works identically
2. Maintain Exports: Keep public API unchanged (DownloadWorkflowLogs, DownloadWorkflowLogsFromStdin, LogsDownloadOptions, StdinLogsOptions)
3. Extract helpers first: Start with applyRunFilters + buildProcessedRun to eliminate duplication before splitting files
4. Incremental Changes: Split one module at a time; keep the build green at each step
5. Run Tests Frequently: Verify make test-unit passes after each split
6. Update Imports: All new files are in the same cli package — no import path changes needed

Acceptance Criteria

• logs_orchestrator.go is split into 5 focused files
• Each new file is under 500 lines
• Duplicate filter + ProcessedRun build logic is extracted into shared helpers
• All tests pass (make test-unit)
• Test coverage is ≥80% for new filter and render files
• No breaking changes to public API
• Code passes linting (make lint)
• Build succeeds (make build)

Priority: Medium
Effort: Medium (~3–5 focused PRs)
Expected Impact: Eliminates ~250 lines of duplication, improves testability of filter logic, reduces cognitive load when navigating log orchestration code

Generated by 🧹 Daily File Diet · 60.7 AIC · ⌖ 19 AIC · ⊞ 6.8K · ◷

• expires on Jul 9, 2026, 5:30 AM UTC-08:00