feat(conversations): show a Deploying… chip on cards mid-deploy #3

gabrielvidal · 2026-08-09T23:18:13+02:00

gabrielvidal commented

2026-08-09 23:18:13 +02:00

Summary

Conversation cards had no indication when a running conversation was in the
middle of deploying — the CI/CD-style stage checks (StatusChecks) only turn
"Deployed" on after the fact, once the deploy has already finished, and
ConversationListElement (the shared card in the home rail / drawer / list
page) didn't render deploy state at all. This adds a [loader] Deploying…
chip, shown while a deploy command is in flight.

Key changes

backend/conversations.py — track a deploy call (a Bash command matching
the existing deploy regex, or the deploy-html skill) as open from its
tool_use to its tool_result, exposed as deploying: bool on the parsed
summary (ParserState.deploying_since / _is_deploy_call).
backend/main.py — _is_deploying() gates that raw signal the same way
_running_agents() already gates runningAgents: only true while the
conversation's own state is "running", so a dangling open call from an
interrupted/dead run never shows as deploying. Wired into all three summary
call sites (_conversation_cards, conversation_summary, conversation_detail).
backend/schemas.py — deploying: Optional[bool] on ConversationSummary.
frontend/openapi.json + src/generated/model/* — regenerated (orval) to
pick up the new field.
ConvMetaBits.tsx — new DeployingBadge component: an amber pill with a
spinning Loader2 + "Deploying…", styled to match the existing
RunningAgentTags chip.
ConversationListElement.tsx and Conversations.tsx (the two places the
card/tag row is rendered) — render DeployingBadge next to
RunningAgentTags, gated on running && c.deploying.

Key decisions

Detected the deploy in flight by tracking the open tool call directly
(mirroring the existing agent_calls/runningAgents pattern), rather than
adding a new conv-meta.sh deploying stamp fired from the deploy skill
scripts. This keeps the whole feature inside this repo (no homelab-repo
skill changes needed) and needs no new sidecar field — it's derived from the
transcript exactly like the existing "deployed" auto-detection.
Reused the same regex that already lights the "deployed" lifecycle stage
(_DEPLOY_CMD_RE, factored out of _LIFECYCLE_PATTERNS) for real deploy
commands, but deliberately excluded the conv-meta ... deployed stamp
pattern from triggering "in flight" — that command only records a deploy
that already finished, so treating it as "deploying" would flicker the chip
on for a moment right after the real deploy is already done.

Changelog

Added: conversation cards now show a "Deploying…" chip while a deploy
command they issued is still running.

Test notes

npx tsc --noEmit in frontend/ — clean.
Backend: re-dumped frontend/openapi.json from app.openapi() via the
homelab-ai-agent image and regenerated types with npm run gen:api;
imported backend/main.py inside the same image to confirm it still loads.
Visual check: npm run build:mock + vite preview, drove the mock DB
(window.__mock.db()) to flip a running seeded conversation's deploying
to true and published a meta event, then screenshotted the home page's
Running rail — see below.

Screenshots

## Summary Conversation cards had no indication when a running conversation was in the middle of deploying — the CI/CD-style stage checks (`StatusChecks`) only turn "Deployed" on after the fact, once the deploy has already finished, and `ConversationListElement` (the shared card in the home rail / drawer / list page) didn't render deploy state at all. This adds a `[loader] Deploying…` chip, shown while a deploy command is in flight. ## Key changes - `backend/conversations.py` — track a deploy call (a `Bash` command matching the existing deploy regex, or the `deploy-html` skill) as open from its `tool_use` to its `tool_result`, exposed as `deploying: bool` on the parsed summary (`ParserState.deploying_since` / `_is_deploy_call`). - `backend/main.py` — `_is_deploying()` gates that raw signal the same way `_running_agents()` already gates `runningAgents`: only true while the conversation's own state is `"running"`, so a dangling open call from an interrupted/dead run never shows as deploying. Wired into all three summary call sites (`_conversation_cards`, `conversation_summary`, `conversation_detail`). - `backend/schemas.py` — `deploying: Optional[bool]` on `ConversationSummary`. - `frontend/openapi.json` + `src/generated/model/*` — regenerated (`orval`) to pick up the new field. - `ConvMetaBits.tsx` — new `DeployingBadge` component: an amber pill with a spinning `Loader2` + "Deploying…", styled to match the existing `RunningAgentTags` chip. - `ConversationListElement.tsx` and `Conversations.tsx` (the two places the card/tag row is rendered) — render `DeployingBadge` next to `RunningAgentTags`, gated on `running && c.deploying`. ## Key decisions - Detected the deploy in flight by tracking the open tool call directly (mirroring the existing `agent_calls`/`runningAgents` pattern), rather than adding a new `conv-meta.sh deploying` stamp fired from the deploy skill scripts. This keeps the whole feature inside this repo (no homelab-repo skill changes needed) and needs no new sidecar field — it's derived from the transcript exactly like the existing "deployed" auto-detection. - Reused the same regex that already lights the "deployed" lifecycle stage (`_DEPLOY_CMD_RE`, factored out of `_LIFECYCLE_PATTERNS`) for real deploy commands, but deliberately excluded the `conv-meta ... deployed` stamp pattern from triggering "in flight" — that command only *records* a deploy that already finished, so treating it as "deploying" would flicker the chip on for a moment right after the real deploy is already done. ## Changelog - Added: conversation cards now show a "Deploying…" chip while a deploy command they issued is still running. ## Test notes - `npx tsc --noEmit` in `frontend/` — clean. - Backend: re-dumped `frontend/openapi.json` from `app.openapi()` via the `homelab-ai-agent` image and regenerated types with `npm run gen:api`; imported `backend/main.py` inside the same image to confirm it still loads. - Visual check: `npm run build:mock` + `vite preview`, drove the mock DB (`window.__mock.db()`) to flip a running seeded conversation's `deploying` to `true` and published a `meta` event, then screenshotted the home page's Running rail — see below. ## Screenshots ![deploying-badge_20260809-231713.jpeg](https://git.gabvdl.xyz/attachments/2be7c9fc-6eb1-4e9c-bf4c-5b99bce3638a)

deploying-badge_20260809-231713.jpeg

79 KiB

gabrielvidal self-assigned this 2026-08-09 23:18:13 +02:00

gabrielvidal added 1 commit 2026-08-09 23:18:13 +02:00

feat(conversations): show a "Deploying…" chip on cards mid-deploy 2befaeca54

Track a deploy command (Bash matching the deploy regex, or the
deploy-html skill) as in-flight from tool_use to its tool_result, and
surface it as a gated `deploying` field (only true while the
conversation itself is running) — same shape as `runningAgents`. The
list card renders an amber spinner pill next to the subagent chips.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

gabrielvidal merged commit b5b1029fc0 into main

2026-08-09 23:22:30 +02:00

gabrielvidal referenced this issue from a commit

2026-08-09 23:22:30 +02:00

Merge pull request 'feat(conversations): show a Deploying… chip on cards mid-deploy' (#3) from deploying-loader into main

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gabrielvidal/ai-agent#3