What happens
In a client paired to one server (Local) with a second server (Remote) added as an environment, a thread that lives on Remote shows A2A messages from a peer agent as From Unnamed participant. Both the received-message cards in the timeline and the queued-message row show it. If the same thread is opened from Remote's own origin, the same messages show the sender's name ("From Agent Peering Smoke Test").
Found during the poll-mode smoke for #399, but it doesn't depend on poll mode. Any peer sender in a thread on a secondary environment should show it.
Repro
- Serve two peered servers, for example
scripts/j5/pr-env.sh <pr> --peer.
- Pair a browser with Local, then add Remote under Settings → Connections → Add environment.
- Create a Squadron and an agent thread on each server, and have Local's agent message Remote's agent.
- Open Remote's agent thread in that browser, served from Local's origin: the sender is "Unnamed participant".
- Open the same thread from a browser paired directly to Remote's origin: the sender's name shows.
What I checked
- Remote's ledger has the label: every
message.received row from the peer carries senderLabel. peerSenderLabelStatement in ClientReadsService.ts would resolve it.
- From Local's origin, the client sends no request to
/api/j5/a2a/client-reads/participant-identities for Remote at all; this was watched with Playwright network events for 10 s after load.
Reading
useParticipantLabels (apps/web/src/j5/a2a/ParticipantIdentitiesClient.ts) calls readParticipantLabels (archiveFlowClient.ts). That returns an empty map without a request when readPreparedConnection(environmentId) is still null. For a secondary environment the prepared connection usually isn't ready on first render. The hook's effect depends only on [environmentId, key], so when the connection arrives it never runs again, and the labels stay empty until the participant set changes.
A fix would likely make the hook depend on the prepared connection, or retry when it becomes available.
Context: #399 (peering poll mode). Not part of that stack.
What happens
In a client paired to one server (Local) with a second server (Remote) added as an environment, a thread that lives on Remote shows A2A messages from a peer agent as From Unnamed participant. Both the received-message cards in the timeline and the queued-message row show it. If the same thread is opened from Remote's own origin, the same messages show the sender's name ("From Agent Peering Smoke Test").
Found during the poll-mode smoke for #399, but it doesn't depend on poll mode. Any peer sender in a thread on a secondary environment should show it.
Repro
scripts/j5/pr-env.sh <pr> --peer.What I checked
message.receivedrow from the peer carriessenderLabel.peerSenderLabelStatementinClientReadsService.tswould resolve it./api/j5/a2a/client-reads/participant-identitiesfor Remote at all; this was watched with Playwright network events for 10 s after load.Reading
useParticipantLabels(apps/web/src/j5/a2a/ParticipantIdentitiesClient.ts) callsreadParticipantLabels(archiveFlowClient.ts). That returns an empty map without a request whenreadPreparedConnection(environmentId)is still null. For a secondary environment the prepared connection usually isn't ready on first render. The hook's effect depends only on[environmentId, key], so when the connection arrives it never runs again, and the labels stay empty until the participant set changes.A fix would likely make the hook depend on the prepared connection, or retry when it becomes available.
Context: #399 (peering poll mode). Not part of that stack.