[BUG] [alpha] Call Stack empty state says `No stack frames` when no threads are available

[angelicameri]

Project

ide

Description

In the mounted Call Stack panel, a paused debug session can temporarily have no available threads:

• before threads load,
• after a thread list refresh drops to zero,
• or when the adapter cannot currently provide thread data.

But CallStackPanel does not distinguish that state from an empty frame list.

Visible result:

• the panel has no thread rows,
• there are no frames shown,
• but the empty-state text says only:
  • No stack frames

So the UI can blame frames even when the real state is that no threads are available at all.

Root Cause

The mounted CallStackPanel only renders thread rows when there are multiple threads:

• /src/components/debugger/CallStackPanel.tsx:121
  • const hasMultipleThreads = () => threads().length > 1;
• /src/components/debugger/CallStackPanel.tsx:178
  • thread list is gated behind showThreads() && hasMultipleThreads()

That means:

• threads().length === 0 renders no thread UI,
• threads().length === 1 also renders no thread UI,
• and there is no separate fallback for the zero-thread case.

The only empty-state message in the paused path is driven by frame count alone:

• /src/components/debugger/CallStackPanel.tsx:201-204
  • when frames().length === 0, show No stack frames

By contrast, the older CallStackView explicitly distinguished the no-threads state:

• /src/components/debugger/CallStackView.tsx:193-205
  • when debug.state.threads.length === 0, it shows No threads available

So the mounted panel regressed from a thread-aware empty state to a frame-only fallback, which can misdescribe the actual debugger state.

Error Message

Debug Logs

System Information

- Cortex IDE `alpha`
- Platform: any

Screenshots

output.mp4

Steps to Reproduce

1. Start a debug session.
2. Reach a state where the debugger is paused but the thread list is empty or temporarily unavailable.
3. Open Call Stack.
4. Observe the empty-state message.

Expected Behavior

If no threads are available, the panel should say so explicitly.

It should not describe that state as only a missing stack-frame list.

Actual Behavior

The mounted panel falls through to No stack frames even when the real state is that there are no available threads.

Additional Context

This is not the same as the current live/local Call Stack issues:

• live #20612 Debug: Focus Call Stack command does nothing
• live #29890 Run and Debug: Call Stack entries are mouse-only (clickable divs not focusable, no role/aria-selected)
• live #36743 Debugger Missing Thread Selection UI (Functional Gap)
• live #37394 Call Stack single-click selects a frame but only double-click actually navigates to it
• live #37408 Call Stack switching threads does not refresh Watch expressions, so watch values can stay stale
• live #37418 Call Stack copy tooltip hardcodes Ctrl+C on macOS
• live #37430 Call Stack can keep highlighting the wrong thread after a later stop event
• live #37524 Call Stack selecting a different frame does not retarget Disassembly view because DisassemblyView still uses stackFrames[0]
• live #37546 Call Stack selecting a thread with no frames can leave the Variables panel showing stale scopes from the previous frame
• live #37588 Call Stack copy button remains active with no frames and can overwrite the clipboard with an empty string
• live #37592 Call Stack thread rows can be indistinguishable when different threads share the same name
• live #37624 Call Stack Copy Call Stack can drop visible source names and replace them with unknown for pathless frames
• live #37628 Call Stack Restart Frame button can disappear when the adapter omits canRestart on frames
• live #37752 Call Stack presentationHint: "label" rows still behave like real selectable frames
• local bug-report-call-stack-right-clicking-a-frame-falls-back-to-the-native-context-menu-and-loses-copy-frame-actions.md

Those issues cover command routing, accessibility, thread selection affordance, frame interaction, stale watch/variables/disassembly state, copy issues, restart-frame visibility, label-row semantics, and lost frame context actions.

This report is specifically about the mounted empty-state contract:

• zero available threads,
• zero visible thread rows,
• but a frame-only fallback message.

Why it is different:

• the existing no-frames-thread issue is about stale Variables after selecting a thread that has zero frames,
• this issue is about the panel's own empty-state text misdescribing a zero-thread state,
• and the root cause is the mounted panel having no thread-aware zero-thread fallback at all.

Duplicate Check

Re-checked local (bug-3, bugs-codex) and targeted live repo searches across open and closed issues with:

• "Call Stack" "No threads available"
• "Call Stack" "No stack frames" no threads
• "Call Stack" empty state no threads available
• local grep for No stack frames, No threads available, Call Stack empty state, and existing Call Stack drafts

Findings:

• Local: no matching report found for this specific zero-thread empty-state mismatch in the mounted CallStackPanel.
• Live repo: no matching issue found in PlatformNetwork/bounty-challenge for this exact no threads available vs No stack frames Call Stack bug at check time (2026-03-25 UTC).
• Closest live/local items are different:
  • selecting a thread with zero frames leaving stale Variables,
  • copy behavior with no frames,
  • missing thread-selection affordance in general.
• Why they are different:
  • none of those reports cover the mounted CallStackPanel lacking a zero-thread fallback and therefore showing No stack frames when the actual state is that there are no available threads.

[echobt]

✅ Validated

VALID bug report. The issue correctly identifies that CallStackPanel shows "No stack frames" when there are zero threads available, instead of indicating no threads are available.

Screenshot/video analysis: The video clearly shows the Call Stack panel with "No stack frames" message, directly demonstrating the reported issue.

Code verification (src/components/debugger/CallStackPanel.tsx):

• Line 121: hasMultipleThreads = () => threads().length > 1 - only shows thread UI when >1 thread
• Line 178: Thread list gated behind showThreads() && hasMultipleThreads()
• Lines 201-204: Empty state only checks frames().length === 0 and shows "No stack frames"
• NO handling for threads().length === 0 case to show "No threads available"

The older CallStackView.tsx (line 204) explicitly handles this case with "No threads available" message, confirming this is a regression in the mounted panel.

Component is accessible via ActivityBar → Run and Debug → Call Stack section.

NOT a duplicate of #37546 (stale Variables when switching threads) - different root cause, different symptoms, different code paths.

[hinzwilliam52-ship-it]

I've designed a fix for this issue and am preparing a pull request. Ill post the link here in a moment once i am done

[hinzwilliam52-ship-it]

I have opened a Pull Request with the fix here: #37826

Thanks!