UX Reference: Task Logging System (Separated Per-Task Logs)

Feature Branch: 018-task-logging-v2 Created: 2026-02-07 Status: Draft

1. User Persona & Context

Who is the user?: System Administrator / DevOps Engineer / Developer.
What is their goal?: Monitor task execution in real-time, debug failures by isolating logs from specific components (e.g., Superset API vs. Git operations), and review historical logs of completed tasks.
Context: Using the web dashboard to run migrations, backups, or LLM analysis.

2. The "Happy Path" Narrative

The user starts a migration task and immediately sees the log panel. As the task progresses, logs appear with clear color-coded tags indicating their source (e.g., [superset_api], [git]). The user notices a warning from the superset_api source, clicks the "Source" filter, and selects "superset_api" to isolate those messages. The view instantly updates to show only API-related logs, allowing the user to quickly identify a rate-limiting warning. Once the task finishes, the user refreshes the page, and the logs are still there, fully searchable and filterable.

3. Interface Mockups

UI Layout & Flow

Screen/Component: TaskLogPanel (within Task Details)

Layout: A header with filter controls, followed by a scrollable log area.
Key Elements:
- Level Filter: Dropdown (All, Info, Warning, Error, Debug).
- Source Filter: Dropdown (All, plugin, superset_api, storage, etc.).
- Search Input: Text field with "Search logs..." placeholder.
- Log Area: Monospace font, alternating row backgrounds.
- Progress Bar: Inline bar appearing within a log row when a component reports progress.
States:
- Default: Shows all logs for the current task.
- Filtering: Log list updates as filters are changed (live for running tasks via WS).
- Auto-scroll: Enabled by default; a "Jump to Bottom" button appears if the user scrolls up.

4. The "Error" Experience

Scenario A: Log Loading Failure

User Action: Opens a historical task with thousands of logs.
System Response: A small inline notification: "Failed to load full log history. [Retry]".
Recovery: Clicking "Retry" re-triggers the REST API call.

Scenario B: WebSocket Disconnect

System Response: The log panel shows a "Reconnecting..." status indicator.
Recovery: System automatically reconnects; once back, it fetches missing logs since the last received timestamp.

5. Tone & Voice

Style: Technical, precise, and informative.
Terminology: Use "Source" for component identification, "Level" for severity, and "Persistence" for saved logs.

2.7 KiB Raw Blame History