In a group conversation with another person present, a reply can be held for its owner's private-share permission. If the owner then allows it, the reply is shown, but any @Peer it names is never handed on.
- When the reply is held,
chainOf(turn) is stored on the waiting row (group.ts, around the gate.status === "pending" branch).
- The resume path in
continueWaiting for a held privateShare reply finishes the row as completed and calls activity. It never calls relay, so the stored chain is not used.
The same reply allowed immediately would have relayed. So whether a mentioned Bot answers depends on whether the owner had to be asked first.
Suggested fix: after finish in that branch, call relay with chainFrom(row.details), as the non-held resume branch does. Is there a reason it was left out, for example to avoid relaying content the owner only allowed to be shown? If not, I can send the PR with an integration test.
In a group conversation with another person present, a reply can be held for its owner's private-share permission. If the owner then allows it, the reply is shown, but any
@Peerit names is never handed on.chainOf(turn)is stored on the waiting row (group.ts, around thegate.status === "pending"branch).continueWaitingfor a heldprivateSharereply finishes the row as completed and callsactivity. It never callsrelay, so the stored chain is not used.The same reply allowed immediately would have relayed. So whether a mentioned Bot answers depends on whether the owner had to be asked first.
Suggested fix: after
finishin that branch, callrelaywithchainFrom(row.details), as the non-held resume branch does. Is there a reason it was left out, for example to avoid relaying content the owner only allowed to be shown? If not, I can send the PR with an integration test.