Cell Execution Status isn't clear

[jlewi]

When a cell is running its not clearly indicated in the UI.

@hamelsmu What does Jupyter do?

[hamelsmu]

Proposed Improvements for Cell Execution Status

After reviewing the current implementation and comparing with Jupyter/Colab, here's what we found and what we propose.

Current State

The app already has execution status indicators, but they're subtle:

1. Run button swaps icons: Play → spinning arc → checkmark/error number. The spinner is a small 15×15 amber icon — easy to miss, especially if the cell isn't in view.
2. Left border: Code cells have a border-l-[3px] that only changes on hover (hover:border-amber-400). It doesn't reflect execution state at all.
3. Sequence label: Shown below the run button in text-[10px] text-gray-400 — extremely small and faint. Only appears after completion, nothing during execution.

What Jupyter/Colab Do

Feature	Jupyter	Colab
Running	[*] in prominent left gutter	Spinning circle + blue left border
Completed	[1], [2], etc. (same size as [*])	[1] + green left border
Idle	[ ] (empty brackets)	No indicator
Key insight	The bracket indicator is always visible and the same size across states, so the transition is immediately noticeable	The border color change is persistent and visible even when scrolled

Proposed Changes

1. Dynamic left border color based on execution state (highest impact, lowest effort)

Change the existing border-l-[3px] from hover-only to state-driven:

• Idle: border-transparent (current)
• Running: border-amber-400 (persistent, not just on hover) + optional pulse animation
• Success: border-green-400
• Error: border-red-400

This gives a glanceable, scroll-visible indicator without changing layout.

2. Jupyter-style bracket notation replacing the tiny sequence label

Replace the current text-[10px] sequence number with a properly sized bracket indicator:

• Idle: [ ]
• Running: [*] (with amber color or animation)
• Completed: [1], [2], etc.
• Error: [!] or [E] in red

Use text-xs or text-sm with font-mono so it's actually readable.

3. Subtle background tint during execution (optional, nice-to-have)

Add a very faint amber wash (bg-amber-50/30) to the entire cell while running. This makes it obvious even if you're focused on a different cell.

Files to Change

• app/src/components/Actions/Actions.tsx:
  • Update the cell wrapper className (line 632) to use execution state for border color
  • Update the sequenceLabel logic (lines 403-412) to show [*] during running, [ ] when idle
  • Increase the size/contrast of the sequence label (line 655)
• app/src/components/Actions/icons.tsx: No changes expected (existing icons are fine)

Implementation Complexity

This is a small, focused change — all within Actions.tsx. The state variables (pid, exitCode, sequence) already exist; we just need to use them to drive more visual properties.

Let us know if this direction looks right and we'll implement it.

[hamelsmu]

Additional Findings from Code Review

After deeper analysis of the execution flow, two more issues surfaced that compound the problem:

C. Delayed "Running" state — no optimistic feedback on click

The "running" state is derived from pid !== null && exitCode === null, but the PID only arrives after the stream is established (via the pid stream in bindStreamsToCell). This means there's a noticeable gap between clicking "Run" and the UI showing any busy state — the button stays as a gray play icon during this time, making it feel like nothing happened.

Fix: Set a local runRequested flag immediately on click so the UI shows "busy" optimistically. Clear it when PID or exitCode arrives. Also reset stale pid/exitCode on each new run to avoid briefly flashing old success/error state.

D. WebContainer-backed cells (JS/Observable) never show "running"

The WebContainerConsole component doesn't emit a PID (since there's no OS process), so JS/Observable cells never enter the running state at all — they go straight from idle to success/error. The isRunning check (pid !== null && exitCode === null) is always false for these cells.

Fix: Either pass a stand-in PID (e.g. Date.now()) while the WebContainer promise is in-flight, or plumb a dedicated isRunning boolean that doesn't depend on OS PIDs.

---

These two issues together mean that for many cell executions, users get zero visual feedback that execution has started — which is likely the core of the complaint in this issue.

[hamelsmu]

I reviewed this against the current main codepath, and the proposed direction makes sense overall. The core diagnosis is correct: run feedback is too weak and pid-only state misses cases.

A few implementation notes to make this easier for a new engineer:

1. The left-border suggestion is good, but the code references are slightly stale.
   The card styling is now in app/src/index.css (.cell-card), and the card wrapper in app/src/components/Actions/Actions.tsx currently does not have a dedicated stateful left border. So this needs to be introduced, not just toggled.

2. Prefer an explicit execution state over synthetic PIDs.
   In Actions.tsx, model something like idle | pending | running | success | error and derive UI from that. Set pending immediately on click (before cellData.run()), transition to running on pid, and to success/error on exitCode.

3. WebContainer currently never emits a non-null PID.
   app/src/components/Actions/WebContainer.tsx calls onPid(null) at run start and never sets a PID, so JS/Observable cells cannot show running under pid-based logic. I would add a dedicated onRunningChange(boolean) (or equivalent) rather than fake PIDs, so PID remains tied to real backend process semantics.

4. One more wiring check: I can find a runCodeCell event listener in WebContainer.tsx, but no corresponding dispatcher in web/app/src. While touching this area, confirm JS/Observable execution trigger wiring is actually complete.

5. Tests to add with the fix:

   • Actions.test.tsx: status transitions and visible indicator changes ([ ], [*], [n], [E] + border classes).
   • A small unit test for status derivation logic (especially pending before PID).
   • Manual smoke check with one bash cell and one javascript/observable cell to verify immediate click feedback in both paths.

If we do this, we’ll get clear, immediate feedback without conflating transport/process details with UI state.

[jlewi-openai]

Cleanup review: this is not complete on main. #103 implements an execution-state machine and visible pending/running/success/error indicators, but that PR is still open. Keeping this issue open until the change is merged and verified.