5d8b5e96e3
Followup to PR #2966. The user reported the about:blank symptom on reno-stars and the browser console showed: Failed to launch 'platform-pending:d76977b1-…/bb0dcaf3-…' because the scheme does not have a registered handler. So the agent's "download link" was a `platform-pending:<wsid>/<file_id>` URI — the canonical reference for poll-mode chat uploads (see workspace-server/internal/handlers/chat_files.go:690 + workspace/inbox_uploads.py). PR #2966 only handled `workspace:`, `file:///`, and absolute container paths; the platform-pending scheme fell through to the raw URI which the browser couldn't navigate to. Fix --- - `resolveAttachmentHref`: added a `platform-pending:` branch that resolves to `${PLATFORM_URL}/workspaces/<wsid>/pending-uploads/ <file_id>/content`. Uses the wsid from the URI, NOT the chat's workspace_id — these can differ when a file is forwarded across workspaces (cross-workspace delegation, agent forwarding). - New `isPlatformAttachment(uri)` helper — single source of truth for "this URI requires our auth headers, route through downloadChatFile". Used by both `downloadChatFile` (chip click) and ChatTab's markdown-link override. - ChatTab.tsx markdown-link override now imports `isPlatformAttachment` instead of duplicating the scheme list. Pre-fix this list was duplicated and missed `platform-pending:`. Tests ----- The 4 IME tests still pass; tsc clean. The platform-pending resolution is exercised via the `isPlatformAttachment` SSOT helper (any URI reaching `downloadChatFile` or the markdown override goes through it). A dedicated test for the URL shape would need a more elaborate fixture; manual verification on staging post-deploy is the practical gate. Reported on production reno-stars 2026-05-05. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| __tests__ | ||
| app | ||
| components | ||
| hooks | ||
| lib | ||
| store | ||
| stores | ||
| styles | ||
| types | ||
| middleware.ts | ||