poll_vote

poll_vote is implemented by handlePollVote in src/api/handlers/poll/poll_vote.osl.

Handles the poll vote protocol operation through the resource-specific helper and storage layers.

Access

Gate	Requirement
Authentication	Required by the central API gate.
Central permission	None. Resource, channel, ownership, or hierarchy checks may still apply in the handler/helpers.
Broadcast	Yes. The transport removes the internal marker and filters recipients by channel visibility.

Request

Every request includes cmd: "poll_vote" and may include an opaque listener correlation value.

Field	Validation / meaning
`message_id`	`Read separately by the handler or a shared domain helper`
`option_id`	`Read separately by the handler or a shared domain helper`
`option_ids`	`Read separately by the handler or a shared domain helper`
`poll_id`	`Read separately by the handler or a shared domain helper`

Validator source

This adapter delegates validation to a shared helper. The field table lists values read directly by the handler; follow the collaborators below for the shared domain schema.

Shared validation and domain flow: src/api/helpers/polls/lookup.osl.

Processing path

handleCmd enforces authentication.
dispatchCmd routes poll_vote to handlePollVote.
The adapter validates and normalizes input, then calls its domain collaborators.
Durable mutations complete before the response or event is returned.
onMessage adds the request listener to direct responses and performs any marked broadcast.

Direct collaborators visible in the handler: pollRequest, pollVoteIds, typeof, else, pollSetVotes, usernameFromId, pollResults, pollFromMessage, pollGet, pollByMessage

Responses and events

Response/event command names visible in this adapter: poll_vote.

Validation and domain failures use:

{
  "cmd": "error",
  "val": "<message>",
  "src": "poll_vote",
  "listener": "<copied from request>"
}