Skip to content

fix(hooks): pass mediaUrl/mediaUrls to plugin message_received event metadata#87297

Merged
steipete merged 2 commits into
openclaw:mainfrom
WarrenJones:task/fix-media-metadata-clean
May 28, 2026
Merged

fix(hooks): pass mediaUrl/mediaUrls to plugin message_received event metadata#87297
steipete merged 2 commits into
openclaw:mainfrom
WarrenJones:task/fix-media-metadata-clean

Conversation

@WarrenJones

Copy link
Copy Markdown
Contributor

Summary

  • Add mediaPath, mediaUrl, mediaType, mediaPaths, mediaUrls, mediaTypes to toPluginMessageReceivedEvent metadata
  • Aligns message_received metadata with existing inbound-claim metadata

Test plan

  • Unit tests pass: message-hook-mappers.test.ts asserts media fields in received event metadata
  • Only 2 files changed, 10 lines added — no unrelated commits

@WarrenJones

This comment was marked as spam.

@clawsweeper

clawsweeper Bot commented May 27, 2026

Copy link
Copy Markdown
Contributor

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

@openclaw-barnacle openclaw-barnacle Bot added size: XS triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels May 27, 2026
@clawsweeper

clawsweeper Bot commented May 27, 2026

Copy link
Copy Markdown
Contributor

Codex review: needs real behavior proof before merge. Reviewed May 27, 2026, 6:28 PM ET / 22:28 UTC.

Summary
This PR forwards six canonical media fields into plugin message_received event metadata and adds mapper assertions for the single media fields.

PR surface: Source +6, Tests +4. Total +10 across 2 files.

Reproducibility: yes. from source inspection: current main derives the media fields and forwards them through inbound_claim, but toPluginMessageReceivedEvent omits them before the WhatsApp hook path runs. I did not run a live WhatsApp/plugin repro because this review is read-only.

Review metrics: 1 noteworthy metric.

  • Plugin Hook Metadata Fields: 6 added, 0 removed. message_received is an external plugin hook surface, so maintainers should notice the additive metadata contract before merge.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof from a real setup is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

  • Add redacted real behavior proof showing a plugin message_received handler receiving media metadata for an inbound media message.
  • After proof is added, update the PR body so ClawSweeper re-reviews automatically; if it does not, ask a maintainer to comment @clawsweeper re-review.
  • Have maintainers decide whether these media metadata keys should be documented as stable plugin hook contract.

Proof guidance:
Needs real behavior proof before merge: The PR body only claims unit tests and the comments contain no after-fix real WhatsApp/plugin run; the contributor should add redacted terminal output, logs, copied live output, screenshot, recording, or linked artifact proof. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

  • The PR lacks after-fix real behavior proof from an external contributor; the available evidence is unit-test-only and the real behavior proof check is failing.
  • The PR additively expands the external message_received plugin hook metadata surface with local media paths and media URLs, so maintainers should explicitly accept the API/privacy behavior before merge.
  • A parallel open attempt exists for the same canonical bug, but it also lacks real behavior proof, so maintainers still need to choose one proof-positive landing path.

Maintainer options:

  1. Prove And Accept The Hook Payload (recommended)
    Require redacted real WhatsApp/plugin output showing message_received receives the six media fields, then have maintainers accept the additive metadata contract.
  2. Document The Stable Fields
    If maintainers want these keys to be stable SDK-facing metadata, update the plugin hook docs before merge.
  3. Pick One Canonical Branch
    If maintainers prefer the parallel PR, pause this PR only after that branch has positive real behavior proof and is the chosen landing path.

Next step before merge
Human handling is needed because automation cannot supply the contributor's real behavior proof or choose the permanent plugin metadata contract.

Security
Cleared: No concrete supply-chain or code-execution issue was found; the media reference exposure is handled as an additive opted-in plugin API compatibility risk.

Review details

Best possible solution:

Land one narrow mapper fix after redacted real WhatsApp/plugin proof shows message_received receiving the media fields and maintainers accept the additive hook metadata contract.

Do we have a high-confidence way to reproduce the issue?

Yes from source inspection: current main derives the media fields and forwards them through inbound_claim, but toPluginMessageReceivedEvent omits them before the WhatsApp hook path runs. I did not run a live WhatsApp/plugin repro because this review is read-only.

Is this the best way to solve the issue?

Yes for the code direction: forwarding the already-canonical fields through the existing mapper is the narrow maintainable fix. The merge path still needs real behavior proof and maintainer acceptance of the additive plugin hook payload.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 5cef288d6511.

Label changes

Label justifications:

  • P2: This is a bounded existing-hook bug fix for media-aware plugin workflows without core runtime outage severity.
  • merge-risk: 🚨 compatibility: The PR changes an external plugin hook payload surface by adding media path and URL metadata to message_received events.
  • rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
  • status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body only claims unit tests and the comments contain no after-fix real WhatsApp/plugin run; the contributor should add redacted terminal output, logs, copied live output, screenshot, recording, or linked artifact proof. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed

PR surface:

Source +6, Tests +4. Total +10 across 2 files.

View PR surface stats
Area Files Added Removed Net
Source 1 6 0 +6
Tests 1 4 0 +4
Docs 0 0 0 0
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 2 10 0 +10

What I checked:

  • Root policy read and applied: Root AGENTS.md was read fully from disk; its plugin API compatibility, whole-surface review, and real behavior proof guidance apply because the PR changes plugin hook event metadata. (AGENTS.md:1, 5cef288d6511)
  • Current main drops media on message_received: Current main derives media fields and forwards them on inbound_claim, but toPluginMessageReceivedEvent metadata only includes routing and sender fields, not media fields. (src/hooks/message-hook-mappers.ts:360, 5cef288d6511)
  • WhatsApp hook uses the generic mapper: The WhatsApp inbound hook path derives the canonical context, then calls toPluginMessageReceivedEvent(canonical) before running message_received, so the mapper omission affects the reported WhatsApp path. (extensions/whatsapp/src/auto-reply/monitor/process-message.ts:118, 5cef288d6511)
  • PR diff touches the implicated mapper: The PR head adds mediaPath, mediaUrl, mediaType, mediaPaths, mediaUrls, and mediaTypes to message_received metadata, plus assertions for the single media fields. (src/hooks/message-hook-mappers.ts:384, 17ce3a7c1b51)
  • Latest release still has the gap: Tag v2026.5.26 includes media fields on inbound_claim metadata but still omits them from toPluginMessageReceivedEvent, so the fix is not shipped in the latest release. (src/hooks/message-hook-mappers.ts:360, 10ad3aa16068)
  • Proof is still absent: The PR body and comments show unit-test claims and ClawSweeper review/status comments only; no terminal output, logs, screenshot, recording, or linked artifact demonstrates a real plugin receiving media metadata after the patch. (17ce3a7c1b51)

Likely related people:

  • steipete: Peter Steinberger introduced the shared message hook mapper and later centralized inbound supplemental context, both central to this metadata path. (role: introduced behavior and recent adjacent contributor; confidence: high; commits: caae34cbafab, 1507a9701b83; files: src/hooks/message-hook-mappers.ts, src/hooks/message-hook-mappers.test.ts)
  • huntharo: Harold Hunt authored the merged hook work that passed inbound attachment arrays to plugin metadata, directly adjacent to the fields this PR forwards. (role: adjacent hook metadata contributor; confidence: medium; commits: 7d18799bbeb2, aa1454d1a80c; files: src/hooks/message-hook-mappers.ts, src/hooks/message-hook-mappers.test.ts)
  • mcaxtr: Marcus Castro recently worked on the WhatsApp inbound monitor path that emits the plugin message_received hook. (role: recent WhatsApp inbound contributor; confidence: medium; commits: 458a52610a4d; files: extensions/whatsapp/src/auto-reply/monitor/process-message.ts)
  • vincentkoc: Vincent Koc recently changed plugin hook correlation and routing metadata surfaces around the same plugin event contracts. (role: plugin hook API contributor; confidence: medium; commits: 3bd2ee78b6ac, e593122465e7; files: src/plugins/hook-message.types.ts, src/hooks/message-hook-mappers.ts)
What the crustacean ranks mean
  • 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
  • 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
  • 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
  • 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
  • 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
  • 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
  • 🌊 off-meta tidepool: rating does not apply to this item.

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
  • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
  • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
  • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
  • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
  • Maintainers can also comment @clawsweeper review to request a fresh review only.
  • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
  • Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
  • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

@clawsweeper clawsweeper Bot added rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P2 Normal backlog priority with limited blast radius. merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. labels May 27, 2026
@clawsweeper

clawsweeper Bot commented May 27, 2026

Copy link
Copy Markdown
Contributor

ClawSweeper PR egg

🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat.

Where did the egg go?
  • The egg game starts only after the PR passes the real-behavior proof check.
  • Before that, no creature or rarity is rolled. The treat waits for real proof.
  • This is still just collectible flavor: proof affects review readiness, not creature quality.

@steipete steipete self-assigned this May 27, 2026
@steipete steipete added the proof: override Maintainer override for the external PR real behavior proof gate. label May 28, 2026
@steipete

Copy link
Copy Markdown
Contributor

Maintainer verification for 394712c:

Behavior addressed: plugin message_received hooks now receive the canonical inbound media metadata already available to inbound_claim: mediaPath, mediaUrl, mediaType, mediaPaths, mediaUrls, and mediaTypes.

Real environment tested: local OpenClaw source checkout on macOS; mapper-level behavior verified with the repo Vitest wrapper. Maintainer proof override applied because this is a small pure hook-mapper contract change and no channel/provider runtime setup is needed to exercise provider delivery.

Exact steps or command run after this patch:

node scripts/run-vitest.mjs src/hooks/message-hook-mappers.test.ts
/Users/steipete/Projects/agent-scripts/skills/autoreview/scripts/autoreview --mode branch --base origin/main

Evidence after fix: focused Vitest passed: 1 test file, 12 tests. Autoreview reported no accepted/actionable findings.

Observed result after fix: the received hook metadata assertions cover singular and plural media path/url/type fields.

What was not tested: full live channel delivery with a real external media upload; this patch only forwards fields that are already present in the canonical inbound context.

@openclaw-barnacle openclaw-barnacle Bot removed the triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. label May 28, 2026
@steipete
steipete merged commit 65e2120 into openclaw:main May 28, 2026
110 of 113 checks passed
github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request May 28, 2026
Forward canonical inbound media metadata to plugin message_received hooks so plugins can inspect the same mediaPath, mediaUrl, mediaType, mediaPaths, mediaUrls, and mediaTypes fields already available to inbound_claim.

Verification:
- node scripts/run-vitest.mjs src/hooks/message-hook-mappers.test.ts
- /Users/steipete/Projects/agent-scripts/skills/autoreview/scripts/autoreview --mode branch --base origin/main

Refs: openclaw#87297
Co-authored-by: WarrenJones <[email protected]>
SYU8384 pushed a commit to SYU8384/openclaw that referenced this pull request Jun 3, 2026
Forward canonical inbound media metadata to plugin message_received hooks so plugins can inspect the same mediaPath, mediaUrl, mediaType, mediaPaths, mediaUrls, and mediaTypes fields already available to inbound_claim.

Verification:
- node scripts/run-vitest.mjs src/hooks/message-hook-mappers.test.ts
- /Users/steipete/Projects/agent-scripts/skills/autoreview/scripts/autoreview --mode branch --base origin/main

Refs: openclaw#87297
Co-authored-by: WarrenJones <[email protected]>
sablehead pushed a commit to sablehead/openclaw that referenced this pull request Jun 10, 2026
Forward canonical inbound media metadata to plugin message_received hooks so plugins can inspect the same mediaPath, mediaUrl, mediaType, mediaPaths, mediaUrls, and mediaTypes fields already available to inbound_claim.

Verification:
- node scripts/run-vitest.mjs src/hooks/message-hook-mappers.test.ts
- /Users/steipete/Projects/agent-scripts/skills/autoreview/scripts/autoreview --mode branch --base origin/main

Refs: openclaw#87297
Co-authored-by: WarrenJones <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. P2 Normal backlog priority with limited blast radius. proof: override Maintainer override for the external PR real behavior proof gate. rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. size: XS status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants