Motir

Type: bug · Parent: Epic 4 (current epic — discovered during Epic 4 work) · Code surface owned by: Story 2.5 (issue list, subtask 2.5.3 — the page wiring) crossed with Story 2.3 (the CreateIssueModal from 2.3.3, which 2.5's "New issue" toolbar trigger reuses) · Status: open · Reported by: Yue.

On the project issue list (/issues), after the user clicks + New work item (top-right of the Work Items page in the repro), fills out CreateIssueModal, and submits, the newly-created work item does not appear in the list / tree until the user manually refreshes the page. The create-service obviously succeeds (the row exists on reload), but the list view's rendered data is stale — the projection that getProjectTree (2.5.1) feeds IssueTreeTable / list view is not invalidated when the modal commits a new issue.

Repro: sign in as zhuyue@prodect.co / !QAZ1qaz, open any project → /issues (or the repro test project shown in the screenshot, which had a single row TEST-3). Click + New work item, fill the modal (any title, any kind), submit. The modal closes successfully but the table still shows only the pre-existing rows; reload the page and the new row appears. Same gap whether the user lands in the Tree view or the List view.

Root cause (hypothesis to verify in the fix Subtask). The /issues page is a Server Component that data-fetches from getProjectTree at request time. CreateIssueModal's success path almost certainly does ONE of: (a) close the modal without invalidating any cache (the bug shape), (b) router.refresh() only when mounted from a specific context (e.g. the detail page tree but not the issue-list toolbar trigger), or (c) revalidatePath against a narrower path than /issues. The fix is to make the modal's success callback unconditionally invalidate the list — either via router.refresh() in the trigger's success handler on /issues, or by extending the create service's revalidatePath set to include the project's /issues route. Contrast the 2.5.5 inline-edit path, which already revalidatePaths after commit (per the 2.5.5 description: "Commit is optimistic + revalidates the list") — that's the correct shape, the create path needs to mirror it. Also worth verifying: creating a CHILD work item from inside the tree (Story 2.4.x) refreshes correctly, so the bug may be specifically the toolbar + New work item entry point on the list page.

Acceptance criteria

• After submitting CreateIssueModal from the /issues toolbar + New work item trigger, the new row appears in the list / tree without a manual page reload.
• Same behaviour in BOTH the Tree view and the List view (and any other 2.5 view variants).
• The newly-created item appears at the correct position per the active sort + filters (if filters exclude it, it correctly does NOT appear — the bug is staleness, not sort/filter wiring).
• Creating a child work item from inside the tree (e.g. via the row-context create affordance from Story 2.4) continues to refresh correctly (guard against regression).
• Creating a work item from any OTHER entry point that feeds back into the same list (detail page → "Add child", board → "Add card", etc.) continues to refresh its origin list correctly.
• A Playwright regression in tests/e2e/issue-list-flow.spec.ts (or a sibling) creates an issue via the /issues toolbar and asserts the new row appears in the list before any reload (poll the table for the new title with a tight timeout; do NOT call page.reload()).

Context refs

• app/(authed)/issues/page.tsx + IssueListPage.tsx (or wherever 2.5.3 mounts the toolbar trigger) — the page that needs to revalidate after create
• 2.3.3 CreateIssueModal / CreateIssueProvider / CreateIssueTrigger — the modal + success-callback surface
• workItemsService.createWorkItem (or whichever service the modal POSTs to) — the revalidatePath set on success (likely needs /issues added if it isn't there)
• 2.5.5 (inline edit) — the working precedent: "Commit is optimistic + revalidates the list" — same shape the create path needs to mirror
• 2.5.1 getProjectTree — the projection the list view reads; the cache it sits behind is what must be invalidated
• bug-inline-edit-clipped-when-table-short (Epic-2 — the other list-surface bug filed in the same session); bug-tree-header-misalignment (Epic-2 — the precedent for filing list-surface bugs against the issue list).