fix(web): allow workflow graph view to load without a codebase

[coleam00]

Summary

• Problem: The Graph tab shows "Loading graph..." indefinitely for any workflow run that has no associated project (codebase_id = null).
• Why it matters: CLI-triggered runs and "No project" web runs always have codebase_id = null, making the Graph tab permanently unusable for a significant portion of workflow runs.
• What changed: Removed && !!codebaseCwd from the useQuery enabled gate in WorkflowExecution.tsx. The server already falls back to bundled defaults when cwd is absent — the client now trusts that fallback.
• What did not change: Server-side route logic (GET /api/workflows/:name), getWorkflow API client, all other queries in WorkflowExecution.tsx.

UX Journey

Before

User opens Graph tab for a CLI/no-project run
  → initialData.codebaseId = null
  → codebaseCwd stays undefined (no codebase record to fetch)
  → useQuery enabled = !!workflowName && !!undefined = false
  → workflowDef never populated
  → dagDefinitionNodes = null
  → Graph tab renders "Loading graph..." forever

After

User opens Graph tab for a CLI/no-project run
  → initialData.codebaseId = null
  → codebaseCwd stays undefined (unchanged)
  → useQuery enabled = !!workflowName = true  ← [changed]
  → GET /api/workflows/:name fires (no cwd param)
  → Server falls back to bundled defaults → returns workflow definition
  → workflowDef populated → dagDefinitionNodes resolved
  → Graph tab renders correctly

Architecture Diagram

Before

WorkflowExecution.tsx
  ├── useQuery workflowDef
  │     enabled: !!workflowName && !!codebaseCwd   ← blocks when codebaseCwd is falsy
  │     queryFn: getWorkflow(name, codebaseCwd)
  └── dagDefinitionNodes = workflowDef?.workflow?.nodes ?? null
                                                          ↑ always null for no-project runs

After

WorkflowExecution.tsx
  ├── useQuery workflowDef
  │     enabled: !!workflowName                    ← [~] no longer gated on codebaseCwd
  │     queryFn: getWorkflow(name, codebaseCwd)    (codebaseCwd is undefined → omitted)
  └── dagDefinitionNodes = workflowDef?.workflow?.nodes ?? null
                                                          ↑ populated via server fallback

Connection inventory:

From	To	Status	Notes
WorkflowExecution.tsx	GET /api/workflows/:name	modified	cwd query param now optional instead of required
GET /api/workflows/:name	bundled defaults	unchanged	Server-side fallback already existed

Label Snapshot

• Risk: risk: low
• Size: size: XS
• Scope: web
• Module: web:workflow-execution

Change Metadata

• Change type: bug
• Primary scope: web

Linked Issue

• Closes Workflow graph view stuck on loading when run has no codebase_id #958

Validation Evidence (required)

bun run type-check   # ✅ No errors across all 9 packages
bun run lint         # ✅ 0 errors, 0 warnings (--max-warnings 0)
bun run format:check # ✅ All files formatted
bun run test         # ✅ All suites passed, 0 failures

• All four CI checks pass. Full test suite (2000+ tests across 9 packages) passes.
• Build step (bun run build:web) has a pre-existing Windows/Bun path resolution issue with mdast-util-gfm unrelated to this change; it is not part of the CI pipeline.

Security Impact (required)

• New permissions/capabilities? No
• New external network calls? No
• Secrets/tokens handling changed? No
• File system access scope changed? No

Compatibility / Migration

• Backward compatible? Yes — the server API already accepted an optional cwd param; we're just allowing the client to omit it.
• Config/env changes? No
• Database migration needed? No

Human Verification (required)

• Verified scenarios: Code inspection confirms the enabled gate change and that getWorkflow already accepts cwd as optional. Server route confirmed to have fallback logic.
• Edge cases checked: workflowName still guards against firing when name is unknown. Server 404 for unknown names results in an error state rather than infinite loading.
• What was not verified: Live manual browser test in a running instance (not performed in this session).

Side Effects / Blast Radius (required)

• Affected subsystems/workflows: Graph tab in WorkflowExecution.tsx only.
• Potential unintended effects: For runs with a project assigned, codebaseCwd is still passed as before — no change in behavior. For no-project runs, the server falls back to the first registered codebase then bundled defaults; the returned definition may not match a project-specific override, but this is a strict improvement over infinite loading.
• Guardrails/monitoring for early detection: No new monitoring needed; graph rendering failure is immediately visible in the UI.

Rollback Plan (required)

• Fast rollback command/path: Revert the single line change in WorkflowExecution.tsx — restore && !!codebaseCwd to the enabled gate.
• Feature flags or config toggles: None.
• Observable failure symptoms: Graph tab would revert to showing "Loading graph..." for no-project runs.

Risks and Mitigations

• Risk: Server returns a different workflow definition when cwd is absent (falls back to first registered codebase instead of the run's project).
  • Mitigation: This only affects the graph topology display, not execution. The run's actual execution context is unchanged. For runs that have no project, there is no correct cwd to use anyway — any result is better than infinite loading.

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Improved workflow definition fetching to support server-side fallback resolution when codebase path is unavailable.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: a3049bfb-007d-4023-93cc-7e9955264a07

📥 Commits

Reviewing files that changed from the base of the PR and between 018e8b9 and 688aeea.

📒 Files selected for processing (1)

• packages/web/src/components/workflows/WorkflowExecution.tsx

---

📝 Walkthrough

Walkthrough

The workflow definition fetching in WorkflowExecution.tsx now enables the query based solely on workflowName presence, removing the codebaseCwd requirement. The query function still passes codebaseCwd ?? undefined to the server, which applies fallback codebase resolution when the value is absent.

Changes

Cohort / File(s)	Summary
Query Enablement Logic packages/web/src/components/workflows/WorkflowExecution.tsx	Removed codebaseCwd from the enabled condition of the workflow definition query. Previously required both workflowName and codebaseCwd to be truthy; now only requires workflowName. Enables server-side fallback codebase resolution for runs without an associated codebase.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 A workflow without a home,
Now need not endlessly roam.
The codebase gate is gone away,
The server catches it today.
Fallbacks bloom where blanks once lay! 🌱

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch dev

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coleam00]

🔍 Comprehensive PR Review

PR: #959 — fix(web): allow workflow graph view to load without a codebase
Reviewed by: 3 specialized agents (code-review, test-coverage, comment-quality)
Date: 2026-04-07

---

Summary

This is a clean, minimal one-line bug fix. Removing && !!codebaseCwd from the enabled gate correctly unblocks the workflow graph view for CLI runs and "No project" web runs. The server-side fallback was already correct before this PR. All agents recommend approval.

Verdict: ✅ APPROVE

Severity	Count
🔴 CRITICAL	0
🟠 HIGH	0
🟡 MEDIUM	1
🟢 LOW	3

---

🟡 Medium Issue — Comment wording (optional fix)

Location: packages/web/src/components/workflows/WorkflowExecution.tsx:238-239

The updated comment says the server "falls back to bundled defaults when cwd is absent" — but the actual server behavior has an intermediate step: it first tries the first registered codebase's default_cwd, then falls back to bundled defaults. A developer debugging an unexpected workflow resolution could be confused.

Current:

// Only gated on workflowName — codebaseCwd is optional; the server falls back to bundled
// defaults when cwd is absent (handles CLI runs and "No project" web runs).

Suggested:

// Only gated on workflowName — codebaseCwd is optional; when absent the server tries the
// first registered codebase before falling back to bundled defaults (handles CLI runs and
// "No project" web runs).

Server reference: packages/server/src/routes/api.ts:2082-2084 — listCodebases()[0].default_cwd is tried first.

This is purely a wording improvement — the logic is correct. Fix or skip as you prefer.

---

🟢 Low Issues (informational)

View 3 low-priority observations

Issue	Location	Notes
Double network request for codebase runs	WorkflowExecution.tsx:240-244	Query fires once with cwd=undefined, then again when codebase loads. Bounded by staleTime: Infinity, correct end-state. Accept as-is — adding a more complex gate would violate KISS.
No comment on why codebaseCwd stays in queryKey	WorkflowExecution.tsx:241	The key entry is intentional (separates cwd-present vs. absent cache entries). A future reader might question whether it's stale. Optional inline note.
No component test for enabled gate	WorkflowExecution.tsx:243	Would require React testing infrastructure in @archon/web. Not recommended for this PR — visual regression is immediately obvious in manual QA.

---

✅ What's Good

• Correct root cause: One-line removal is exactly the right fix — no over-engineering.
• Minimal blast radius: 1 file, +3/-3 lines, zero risk of regression elsewhere.
• queryKey correctness: codebaseCwd stays in the key to keep cwd-present and cwd-absent definitions cached separately — this is correct.
• Fail Fast respected: Server 404 for unknown workflow names surfaces via TanStack Query error state — no silent empty UI.
• CLAUDE.md compliance: Type safety ✓, YAGNI ✓, KISS ✓, no silent fallbacks ✓.
• Comment intent clear: New comment explains why codebaseCwd is optional, not just what the gate does.

---

Next Steps

1. Optional: Apply the one-line comment wording fix above
2. Undraft: PR looks ready to undraft once CI passes (ubuntu test passed on prior push)
3. Merge: No blocking issues

---

Reviewed by Archon comprehensive-pr-review workflow
Artifacts: ~/.archon/workspaces/coleam00/Archon/artifacts/runs/045f934040bd9c6a05591c0dae702661/review/

[coleam00]

Self-Fix Report

Commit: 688aeea — pushed to `dev`

Applied Fix

MEDIUM — Comment Oversimplifies Server Fallback Chain
packages/web/src/components/workflows/WorkflowExecution.tsx:238-239

The inline comment described the server fallback as going directly to bundled defaults when `cwd` is absent, skipping the intermediate step where the server first tries the first registered codebase's `default_cwd`. Updated to accurately describe the two-step chain:

Before:
```tsx
// Only gated on workflowName — codebaseCwd is optional; the server falls back to bundled
// defaults when cwd is absent (handles CLI runs and "No project" web runs).
```

After:
```tsx
// Only gated on workflowName — codebaseCwd is optional; when absent the server tries the
// first registered codebase before falling back to bundled defaults (handles CLI runs and
// "No project" web runs).
```

Accepted As-Is

Finding	Severity	Rationale
Double network request for codebase runs	LOW	Bounded by staleTime: Infinity, correct end-state; complex gate would violate KISS
No comment on codebaseCwd in queryKey	LOW	Not critical enough to warrant extra comment noise
No component-level test for enabled gate	LOW	Would require introducing React testing infrastructure to @archon/web; excessive for a one-line fix with immediate visual feedback when broken

Validation

All checks passed: bun run type-check, bun run lint, bun run test.