Conversation
…omplete Once a finished task history's log stream reaches its terminal state, the line-cap select is dropped from the toolbar when the received log is provably complete and its largest pane holds no more lines than the smallest numeric option in LOG_TAIL_LINE_OPTIONS. At that size every option renders the same thing, so the control cannot change what the user sees. "Provably complete" means the request carried no tail parameter, or every pane's line count is strictly below the requested tail. A pane sitting exactly at the cap may have been trimmed server-side, so the select stays visible. The threshold is derived from LOG_TAIL_LINE_OPTIONS rather than a second constant. Line counts are taken across every step and both streams and the decision uses the largest pane, so the control does not flip as the user moves between step or stream tabs. Gating on the terminal stream status avoids the control flickering while lines are still arriving. Running tasks are unchanged: the select stays visible but disabled with its existing tooltip. The stored tail choice and the requests made are untouched.
Guard the derived threshold against an options list with no numeric entry, where Math.min() would return Infinity and hide the select for every finished task. Add coverage proving a short log that ends in a stream error keeps the select, since an aborted stream never proves the log is complete.
There was a problem hiding this comment.
Pull request overview
This PR updates the TaskLogViewer toolbar UX so the “line cap” select is hidden once a finished task’s streamed logs are terminal and provably complete and short enough that every cap option would render the same output.
Changes:
- Derives
SMALLEST_LOG_TAIL_OPTIONfromLOG_TAIL_LINE_OPTIONSand uses it as the hide threshold for finished, complete, short logs. - Adds helpers to compute the maximum line count across all steps and both stdout/stderr panes, preventing UI toggling when switching tabs.
- Expands
TaskLogViewertests to cover hidden/visible edge-cases (below smallest, exactly-at-cap, running, stream error).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| frontend/packages/framework/src/components/TaskLogViewer/TaskLogViewer.tsx | Adds logic to hide the line-cap select for finished, provably-complete logs within the smallest cap; computes max line count across panes. |
| frontend/packages/framework/src/components/TaskLogViewer/tests/TaskLogViewer.test.tsx | Adds test coverage for the new hide/show behavior across key scenarios. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…shold Line counting saturates at one line over the smallest option, so a big "All lines" log no longer pays a full O(total size) pass just to decide the select stays visible. Any pane above the threshold keeps the select whatever the requested cap was, so the exact count past that point is not needed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
TaskLogViewernow drops the line-cap select from the log console toolbar once a finished task history's log stream has reached its terminal state and the received log is provably complete and short. At that size every option inLOG_TAIL_LINE_OPTIONSrenders the same thing, so the control cannot change what the user sees.SMALLEST_LOG_TAIL_OPTIONfromLOG_TAIL_LINE_OPTIONS(smallest numeric value), so changing the options list moves the threshold with no other edit. Guarded against a list with no numeric entry, whereMath.min()of an empty list would beInfinity.streamStatusfrom the existinguseTaskLogscall (it was already returned and discarded) and gate the decision on'finished', so the control does not flicker while a finished history's lines are still arriving.countLines/maxPaneLineCounthelpers that walktextByStepacross every step and both streams and return the largest pane, so the control does not flip as the user moves between step tabs or the stdout/stderr tabs.FormControl/Selectblock in the newshowLogTailSelectflag. Nothing else in the toolbar moved."Provably complete" means either the request carried no
tailparameter (the All lines choice), or every pane's line count is strictly below the requested tail. A pane sitting exactly at the requested cap may have been trimmed server-side, so the select stays visible there. That ambiguity is resolved conservatively on purpose: the failure mode is a redundant control rather than a hidden one the user needed.Acceptance criteria covered
LOG_TAIL_LINE_OPTIONS, no second constant.RUNNINGbehaviour unchanged: visible but disabled with its existing tooltip.sep.taskLogViewer.tailin local storage untouched.An aborted stream (
sep-error) is deliberately not treated as proof of completeness, so the select stays visible there too.Out of scope
No backend or API change. No change to the running-task behaviour, the option list, the default, the local-storage persistence, or any other toolbar control.
Test plan
pnpm --filter @sep/framework exec vitest run src/components/TaskLogViewer— 51 passed.pnpm --filter @sep/framework type-check— clean.oxlint/oxfmt --check— clean (one pre-existing warning inExecutionEventsPanel.tsx, untouched here).New cases: hidden below the smallest option, hidden for a short All lines log, visible at exactly the requested cap, visible when the largest pane exceeds the smallest option (largest-pane rule), visible after a stream error, visible-but-disabled while running.
Code was reviewed before opening this PR and the feedback is folded into the second commit.