signals_flow scenario sends non-spec field name 'signal_id' (string per spec, object per fixture) to activate_signal

[EvgenyAndroid]

Summary

The signals_flow scenario in lib/testing/scenarios/signals.js calls activate_signal with two bugs:

1. Wrong field name: signal_id is sent instead of signal_agent_segment_id. signal_id does not exist in /schemas/3.0.0/signals/activate-signal-request.json.
2. Wrong type: The fixture passes the full SignalID object { source, agent_url, id } from get_signals rather than unwrapping the string ID. The spec types signal_agent_segment_id as string (x-entity: "signal_activation_id").

Repro

Any signals-only agent with strict schema validation. The agent will reject or silently drop the activate_signal call because the required field is absent and the value shape is wrong.

Fixture location

node_modules/@adcp/client/dist/lib/testing/scenarios/signals.js lines 82–89

Fix

-{ signal_id: signal, ... }
+{ signal_agent_segment_id: signal.id, ... }

1. Rename signal_id —> signal_agent_segment_id
2. Unwrap .id from the SignalID object before passing (pass the string, not the object)
3. Verify destination —> destinations (plural) while in this block

Schema reference

/schemas/3.0.0/signals/activate-signal-request.json
-required: ["idempotency_key", "signal_agent_segment_id", "destinations"]
-signal_agent_segment_id: { type: "string", x-entity: "signal_activation_id" }

[bokelley]

Triage

Classification: Bug (testing/conformance)
Bucket(s): conformance (label not present in repo — flagged in run summary)
Status: drafting-pr
Milestone: omitted

What the experts said:

• ad-tech-protocol-expert: The three specific bugs alleged (wrong field name signal_id, SignalID object type, singular destination) are false against 5.21.1 — current source already uses signal_agent_segment_id: signal.signal_id (string), destinations (plural). The reporter appears to have confused the GetSignalsResponse.signals[].signal_id (SignalID object) with AgentProfile.supported_signals[].signal_id (the string profile field, mapped from signal_agent_segment_id). However, a real related bug was found: the governance advisory block (testSignalsFlow lines 76–107) silently never fires because it re-parses signalsStep.response_preview looking for keys that don't exist in that formatted shape.
• code-reviewer: Confirmed the three reported bugs don't exist in 5.21.1. Confirmed the governance advisory bug as real — withRestrictedAttrs and withPolicyCategories are always empty arrays because the JSON.parse never finds the expected keys.

My take: The specific bugs you reported are not present in the current published 5.21.1 source — signal_agent_segment_id (string) and destinations (array) are already correct. The confusion likely comes from AgentProfile.supported_signals[].signal_id sharing a name with GetSignalsResponse.signals[].signal_id (a SignalID object) — they're different fields at different layers. However, triage did surface a real related bug: the governance advisory block was always a no-op due to a JSON parse mismatch. Drafting a fix PR for that now.

Drafted fix: #1036 — discoverSignals now returns the raw wire signals array alongside the digested profile, so the governance advisory can correctly inspect restricted_attributes/policy_categories extension fields.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01HVTtnJtpj9dqwJQGngjAts

---

Generated by Claude Code

[bokelley]

Verified: this fixture bug was fixed in commit fc34114 (2026-03-21), which shipped in 5.24.0 (current latest before the in-flight 5.25.0).

src/lib/testing/scenarios/signals.ts lines 152-154 now read:

```ts
client.activateSignal({
signal_agent_segment_id: signal.signal_id, // ✅ correct field name
destinations: [destination], // ✅ plural, wrapped
idempotency_key: randomUUID(),
})
```

All three bugs from the report are resolved:

1. ✅ Field name signal_id → signal_agent_segment_id
2. ✅ Type fixed — passing the string signal.signal_id, not the SignalID object
3. ✅ destination → destinations (plural)

The dist/lib/testing/scenarios/signals.js you referenced was from an older published version (≤5.23.x). Upgrading to ≥5.24.0 will pick up the fix. Closing as already-fixed.

[bokelley]

Acknowledged — thanks for the version confirmation, @bokelley. For clarity on #1036: that PR addresses the separate governance advisory bug found during triage (the discoverSignals JSON parse mismatch that made restricted_attributes/policy_categories advisory checks silently no-op), not the three originally reported bugs. #1036 should stay open after this issue closes.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_015z9LyEt4Q1wfhZvSRw99GD

---

Generated by Claude Code