fix(frontend): resolve pinned automation session names outside automation mode - #5939
Conversation
…tion mode Pinning an automation session made it visible in human mode (P2-8), but its title still fell back to "Missing schedule": the pinned sub-query's origin override dropped the trigger expansion needed to resolve the schedule or subscription name whenever the surrounding surface didn't already request it (every human-mode surface, plus the sidebar). Add "trigger" to the pinned query's expansions in useSessionsList/useSessionCardList and to the sidebar's sidebarPinned policy, alongside the origin override, so a pinned automation row resolves its name on every surface.
dosubot
Bot
added
the
size:S
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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. Comment |
Railway Preview Environment
Updated at 2026-08-11T13:33:03.848Z |
1 participant
Symptom
Pinning an automation session made it visible in human/default mode (the P2-8
fix from #5927 works), but its title read "Missing schedule" instead of
the real schedule or subscription name — on the Sessions page's default view,
the Agent Overview / Home card's human "Sessions" section, and (by the same
code path) the sidebar's pinned list.
Before (Sessions page, default mode):
Before (Home card, human sessions section):
(From the post-merge smoke QA on #5927; full walkthrough video at
https://github.com/Agenta-AI/agenta/releases/tag/qa-session-ux-5927.)
Root cause
Confirmed via network inspection: the same pinned session, queried from
automation mode, sent
"expand":["last_message","trigger"]and resolved thename correctly. Queried from human/default mode, the pinned sub-query sent
"expand":["last_message"]— no"trigger"— so the name never resolved.pinnedSessionListArgs()inuseSessionsList.tsanduseSessionCardList.tsoverrides the pin's
originPolicyto"all"(so the row shows up outsideautomation mode, per P2-8) but left
expansionsas whatever the surroundingsurface's own policy requested. Every human-mode surface's policy omits
triggerby design (it's only needed for automation-origin rows), so apinned automation row landing in a human-mode list never asked for the one
field it needs to display its name. The sidebar's
sidebarPinnedpolicy insessionListPolicies.tshas the identical shape (expansions: []) and thesame gap.
Fix
Add
"trigger"to the pinned query's expansions in both hooks (dedupedagainst whatever the surface already requests), and to the
sidebarPinnedpolicy — alongside the existing origin override, not instead of it. A pinned
automation row now resolves its name regardless of which surface's default
policy it's rendered under.
Tests
Updated the existing
pinnedSessionListArgs()unit tests in both hooks toassert the added
"trigger"expansion (and added a case confirming it isn'tduplicated when the surface already requests it), plus the
sessionListPoliciesand sidebarsessionOptionstests for thesidebarPinnedpolicy change.Verification
pnpm --filter @agenta/sessions test:unit— 38/38 passpnpm --filter @agenta/oss test:unit— 480/480 pass (1 pre-existing skip)pnpm --filter @agenta/oss exec tsc --noEmit— cleanpnpm --filter @agenta/sessions run types:check— cleanpnpm lint-fix— clean (only pre-existing, unrelated warnings elsewhere)restart; will confirm the pinned name resolves on the Sessions default
view, the Home card, and the sidebar once it's back up.
Found during post-merge smoke QA of #5927 (session UX interface). That stack
is already merged, so this regression fix lands as its own PR rather than an
amendment.
Do not merge — Mahmoud reviews and merges.