fix(media): normalizeMediaSource should handle uppercase FILE:// URI schemes#103490
Conversation
01418ba to
339b893
Compare
|
Codex review: needs real behavior proof before merge. Reviewed July 10, 2026, 7:05 AM ET / 11:05 UTC. Summary PR surface: Source 0, Tests +2. Total +2 across 2 files. Reproducibility: yes. from source inspection: uppercase Review metrics: none identified. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Refresh the branch against current main, retain the centralized case-insensitive prefix normalization and focused regression coverage, then merge after redacted real-checkout parser output confirms the corrected attachment extraction. Do we have a high-confidence way to reproduce the issue? Yes from source inspection: uppercase Is this the best way to solve the issue? Yes. Updating the existing shared pre-validation normalizer is the narrowest maintainable solution and avoids duplicating scheme-case handling across media-directive and Markdown-image callers. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against dff4c634f1a5. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source 0, Tests +2. Total +2 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
18f871a to
1cc86bb
Compare
URI schemes are case-insensitive per RFC 3986. normalizeMediaSource only matched lowercase 'file://', so MEDIA:FILE:///tmp/generated.png was left in assistant text instead of being extracted as a local media attachment. Replaced startsWith + replace with a case-insensitive regex to handle FILE://, file://, and any mixed-case variant. Fixes openclaw#103473 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
1cc86bb to
73f5b3a
Compare
|
Land-ready at exact head Maintainer follow-up after fresh autoreview:
Proof:
Known proof gaps: none for the touched parser and outbound staging path. |
|
Merged via squash.
|
…schemes (openclaw#103490) * fix: normalizeMediaSource should handle uppercase FILE:// URI schemes URI schemes are case-insensitive per RFC 3986. normalizeMediaSource only matched lowercase 'file://', so MEDIA:FILE:///tmp/generated.png was left in assistant text instead of being extracted as a local media attachment. Replaced startsWith + replace with a case-insensitive regex to handle FILE://, file://, and any mixed-case variant. Fixes openclaw#103473 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> * fix(media): handle spaced uppercase file URLs --------- Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>
What Problem This Solves
MEDIA:directives using an uppercaseFILE://URI scheme are left in assistant text instead of being extracted as local media attachments. Uppercase unquoted file URIs containing spaces can also be split and truncated instead of being reassembled as one attachment path. Per RFC 3986, URI schemes are case-insensitive, soMEDIA:FILE:///tmp/generated.pngshould behave likeMEDIA:file:///tmp/generated.png.Issue: #103473
Why This Change Was Made
The outbound parser used separate case-sensitive checks for prefix removal and spaced-path recovery. It now uses one anchored, case-insensitive file-URL predicate for both decisions, keeping the behavior local to the canonical parser and leaving downstream media access policy unchanged.
User Impact
Assistant or tool output using non-lowercase file URI schemes now delivers the intended local attachment without exposing the raw directive or truncating paths containing spaces. Lowercase behavior and existing safety rejection remain unchanged.
Evidence
73f5b3a2319fbc47dd1e756dace7acd55c945789; patch-identical rebase of the validated head onto currentmain.run_621c85721cd0on the patch-identical pre-rebase head:pnpm test src/media/parse.test.ts, 61/61 passed.run_e6e856990bcaat2d54be31ba68edb070732dc3d0511afb7c5ad32d: both uppercase cases reproduced red while lowercase and safety controls passed.oxfmt --checkandgit diff --checkpassed.