<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "bug" label: - https://gitlab.com/gitlab-org/cli/-/issues/?label_name%5B%5D=type%3A%3Abug and verify the issue you're about to submit isn't a duplicate. ---> ### Checklist <!--Please test the latest versions, that will remove the possibility that you see a bug that is fixed in a newer version.--> - [x] \[ \] I'm using the latest version of the extension (Run `glab --version`) - 2026/08/16 17:18:57.290079 c - [x] Operating system and version: _WSL - Ubuntu 22.04_ - [x] Gitlab.com or self-managed instance? _self-managed_ - [x] GitLab version (if self-managed) 19.2 - [x] I have performed `glab auth status` to check for authentication issues - [x] Run the command in debug mode (like `GLAB_DEBUG=true glab mr list`) and attach any useful output ### Summary In the interactive glab ci view TUI, navigating into a child/downstream\ pipeline (by pressing Enteron a trigger job, marked») correctly shows\ that pipeline's job list. But pressing Enter on a job inside the child\ pipeline to view its log/trace instead shows the log of an unrelated job\ from the parent pipeline. <!--Summarize the bug encountered concisely--> ### Environment <!--on POSIX system (Linux, MacOS), run bash -c 'printf -- "- OS: %s\n- SHELL: %s\n- TERM: %s\n- GLAB: %s" "$(uname -srm)" "$SHELL" "$TERM" "$(glab --version)"' and replace the following section with the result. If you use non-POSIX system, fill in the section manually: - OS: Your operating system including version and architecture (Windows 11 - AMD64, MacOS Sonoma - ARM64) - SHELL: Your shell (bash, fish, zsh, ...) - TERM: Your terminal emulator (Kitty, Xterm2..) - GLAB: result of running `glab --version` (glab version 1.32.0 (2023-08-18))--> - OS: WSL - Ubuntu 22.04 - SHELL: bash - TERM: Windows Terminal - GLAB: 2026/08/16 17:18:57.290079 c <!--Please include any other information that you believe might be relevant in debugging. For example, you may include a shell framework like oh-my-zsh or other customizations like editing the prompt (PS1, PS2, and others).--> Other: ### Steps to reproduce 1\. Have a pipeline whose \`.gitlab-ci.yml\` triggers a child pipeline (a job with \`trigger: include: ...\`), where the child pipeline has at least one job. 2\. Run \`glab ci view\` against that pipeline. 3\. Navigate to the trigger job and press \`Enter\` to descend into the child pipeline. The child pipeline's job list renders correctly. 4\. Select a job inside the child pipeline and press \`Enter\` to view its log/trace. 5\. The resulting log will be a random job from the parent pipeline <!--How one can reproduce the issue - this is very important--> ### What is the current _bug_ behavior? The log/trace shown is not the selected child-pipeline job's — it's a job from the parent (top-level) pipeline, seemingly picked arbitrarily (often appears to be the first job in the parent pipeline). <!--What actually happens--> ### What is the expected _correct_ behavior? Pressing \`Enter\` on a job inside a child pipeline should display that exact job's own log/trace, regardless of what pipeline or job was viewed previously in the same session. <!--What you should see instead--> ### Relevant logs and/or screenshots <!--- Paste the activity log from your command line--> ### Possible fixes Root cause is in \`internal/commands/ci/view/view.go\`: the \`Enter\`-to-view-logs path (inside \`jobsView\`) and the \`Ctrl+Space\` path (inside \`inputCapture\`) both fetch the trace via \`ciutils.RunTraceSha(ctx, apiClient, w, projectID, commitSHA, curJob.Name)\`, where \`projectID\`/\`commitSHA\` are captured once from the top-level pipeline when the TUI starts and never updated as the user navigates into child pipelines. The correct pipeline info is already there (because the UI renders correctly using it) but it isn't used to fetch the logs. Because the job is resolved by name against the wrong (parent) pipeline, it seems to fall back to a different job entirely (\`internal/api/pipeline.go: PipelineJobWithSha\`/\`pipelineJobsWithSha\`). Separately, the tview page caching a job's rendered log is keyed only by job name (\`"logs-" + job.Name\`), so a job with the same name in a different pipeline reuses a stale cached page instead of fetching a new trace. I have a fix ready that resolves the job by ID (like \`glab ci trace\` and this view's own cancel/retry actions already do) scoped to whichever pipeline is currently being viewed, and keys the cached log page by job ID instead of name. Have a fix that seems to work, but going to test and review a bit more before I open an MR with it <!--If you can, link to the line of code that might be responsible for the problem-->