`conformance_multitenant` workflow row is stale vs the workflow-event schema (missing `d` tag → 400)
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
## Environment
- Relay: local build from `block/buzz` main (2026-07-24), `buzz-relay`.
- Test: `crates/buzz-test-client/tests/conformance_multitenant.rs`, module
`workflows::workflow_trigger_is_community_confined`.
- Re-verified at `38bf642f` (main, 2026-08-05): the relay still rejects with
exactly this string
(`crates/buzz-relay/src/handlers/command_executor.rs:668`) and the test's
workflow builder is unchanged, so the row still fails at setup.
## What happens
The test fails at **setup**, not at the isolation assertion:
```
thread 'workflows::workflow_trigger_is_community_confined' panicked at
crates/buzz-test-client/tests/conformance_multitenant.rs:1706:
POST /events to http://a.localhost:3100 returned HTTP 400 Bad Request:
{"error":"invalid: missing d tag (workflow_id)"}
```
The test tries to create a workflow event, but the relay rejects it as missing
a `d` tag (workflow_id). The workflow is never created, so the isolation
property it means to check (a workflow trigger is confined to its community) is
never exercised — this is a false red, not an isolation failure.
## Why
Version skew: the relay's workflow-event validation now requires a `d` tag
(workflow_id), but the conformance test's workflow-creation helper doesn't add
one.
## Fix
Update the test's workflow-event builder to include the `d` / workflow_id tag
matching the current relay schema, so the row exercises the community-confinement
assertion again. (The sibling row `workflows::approval_token_is_community_confined`
is already a `pending_lane` `todo!()` stub — separate work.)
Contributor guide
Assessment
This issue has not been assessed yet.