Messages

The URL must match this instance's discovered media /attachments/ path. The GET sends no Authorization header, follows no redirects, stores no cached copy and never falls back to proxyUrl. The timeoutMs option defaults to the client's rest.defaultTimeoutMs, 30,000 unless configured, for endpoint discovery, waiting for a media slot and downloading. By default four media downloads can run at once (rest.mediaConcurrency), separately from REST and uploads, without waiting for bot API rate limits. Cancellation waits for response-reader cleanup, but cannot undo bytes already received

Size and expiry metadata do not prove that the URL is available or the bytes are safe. Expected failures contain a safe reason and status, including busy, without the URL or response body. Discovery and download transport failures retain a sanitized cause with a safe transport code when available, never the raw error

The frozen result has one original and refreshed pair per input in the same order. A string outside this instance's attachment URL space is returned unchanged by Fluxer. Refreshing does not check attachment existence, community or channel membership, permission to download, or media availability

This method never downloads media and sends the bot credential only to the selected instance's API, never to a requested or refreshed URL. The credentialed POST follows no redirect. Use download explicitly afterward for a returned URL that belongs to this instance

The timeoutMs option defaults to the client's rest.defaultTimeoutMs, 30,000 unless configured, for endpoint discovery, waiting for a REST request slot, rate-limit waits and the limited response read. A confirmed 429 can retry after its required wait. A POST with an unknown outcome or a malformed success is not retried automatically. Cancellation affects only this refresh and waits for request cleanup. HTTP 404 cannot distinguish an older unsupported deployment from an unavailable route or denied access. No refresh happens automatically when reading messages or downloading attachments

The first pull reads the inputs, resolves endpoints, waits for a media slot (four by default, rest.mediaConcurrency) and starts the GET. Media slots are separate from the REST and upload slots. Later pulls read at most one response chunk. No byte packing, spooling, automatic retry or durable storage is added

The URL must match this instance's media /attachments/ path. The GET sends no Authorization header, follows no redirects, caches nothing and never uses proxyUrl. A Content-Length above maxBytes fails before any chunk, but actual byte counting is still enforced

The result can be consumed only once. The timeoutMs option defaults to the client's rest.defaultTimeoutMs, 30,000 unless configured, for the whole download, including pauses between chunks. Ending consumption early, cancellation, failure and client shutdown cancel the body, wait for reader cleanup and release the media slot. Expected failures include safe local busy, network, response, limit and deadline reasons and client closure. Transport failures during discovery, opening or reading retain sanitized causes with safe transport codes when available, never raw errors. Size and expiry metadata do not establish availability or byte safety

The Stream starts when consumed. Expected failures keep their native Effect causes, and scope interruption ends the download

One default deadline, rest.defaultTimeoutMs (30,000 ms unless configured), covers all batch submissions. The submittedBatches field records only earlier HTTP-success submissions, in the report or MessageCleanupError. The rejected or unknown terminal batch is reported separately. These records do not prove each deletion, a deletion count, atomicity or that retrying is safe

The onProgress callback runs synchronously and cleanup continues after it fails. A throw, a rejected promise or a returned or resolved Err result goes to the client-level onError as a progress FailureReport, or is logged at Error. A returned Effect is not run and is reported the same way as a TypeError, so run Effect work explicitly inside the callback. Cancellation can leave the batch being submitted with an unknown outcome. Batches retry only confirmed rate-limit rejections as deleteMany does, never an unknown outcome

Defaults are one accepted message, a 30,000 ms lifetime and 4 MiB of retained selected-message JSON. After channel selection and before filtering, the pending queue allows 256 payloads or 4 MiB of source JSON. Options are copied at registration. Budgets must be positive safe integers, and timeoutMs and optional idleMs must be at most 2,147,483,647 ms

The total timeout starts at registration and never resets. The idleMs timer also starts at registration, then resets after each newly accepted message ID, before its callback. Rejected, queued or duplicate messages do not reset idleMs. Callback time counts toward both deadlines. The earlier deadline wins, with timeout winning ties. Messages processed at or after the deadline are excluded, including slow filter returns. Each accepted ID counts once, and later edits and deletions do not change collected snapshots

The synchronous filter decides acceptance. Filter failure or queue or retained-byte overflow ends this collector with a failure, without partial messages. A slow synchronous filter blocks JavaScript and cannot be preempted. Optional onMessage runs sequentially after filtering, duplicate removal and the retained-byte check. Reaching maxMessages waits for the final callback, and later messages are ignored while it completes. Idle, timeout or stop can retain a message whose callback was cancelled. Pending budgets exclude the active message. Callback failure ends collection with CollectorError reason handler. Callbacks are not retried and their effects are not undone. Filter the bot out when callbacks send acknowledgements, to avoid collecting those acknowledgements

Invalid options are misuse: The default API throws ConfigurationError and the native API dies with it. A client that is not ready returns a collector whose result is CollectorError notConnected, and a client that began shutting down, such as when a handler still running during shutdown registers, returns one whose result is ClientClosedError. A timeout can succeed with no messages. The application still manages the client's lifetime

Collection belongs to the Scope that executes this Effect. Callbacks run with the services available at registration. Closing the registration Scope stops the collector with partial messages, and client shutdown fails it with ClientClosedError. Interrupting a waiter does not stop collection, and there is no AbortSignal option. Scope closure and client shutdown await callback cleanup, and terminal cleanup defects keep their Cause

Defaults are one accepted addition, a 30,000 ms lifetime and 4 MiB of retained reaction JSON. The target and options are copied at registration. After message selection, the pending queue allows 256 payloads or 4 MiB of full source JSON. Optional emoji uses addReaction's input shape and is checked after queueing, before the synchronous filter. Unicode emoji match exact text without a custom ID, and custom emoji match by ID, ignoring name changes. An invalid emoji selector fails with ConfigurationError for emoji

Single events and batch entries follow receive order. A batch uses one pending slot and its entries count individually. Repeated user and emoji pairs count again, and no batching flag is enabled. Removals, clears and message deletion neither undo additions nor stop collection, so this is not a vote tally

The total timeout starts at registration and never resets, and excludes additions processed at or after it, including slow filter returns. Optional idleMs starts then too and resets after each accepted addition, before its callback. Rejected, queued and unprocessed batch entries do not reset it. Callback time counts, and the earlier deadline wins, with timeout winning ties. The timeoutMs and idleMs values must be integers from 1 through 2,147,483,647 ms

Optional onReaction runs sequentially after acceptance and the retained-byte check. Limit completion waits for the final callback. Idle, timeout or stop can retain an addition whose callback was cancelled. Pending budgets exclude the active payload and its unprocessed batch entries. Callback failure ends collection with CollectorError reason handler, and no callback is retried or earlier effect undone. Filter or overflow failure ends with CollectorError without partial results. An invalid target or options are misuse: The default API throws ConfigurationError and the native API dies with it. A client that is not ready returns a collector whose result is CollectorError notConnected, and a client that began shutting down, such as when a handler still running during shutdown registers, returns one whose result is ClientClosedError. The example needs a connected client and an existing message, and idle or timeout may succeed with no reactions

Collection belongs to the Scope that executes this Effect. Callbacks run with the services available at registration. Closing the registration Scope stops collection with partial results, and client shutdown fails it with ClientClosedError. Interrupting a waiter does not stop collection, and there is no AbortSignal option. Terminal cleanup defects keep their Cause

Success follows Fluxer's empty HTTP 202 response. It is not a completed-job report, deletion count, gateway event or proof the channel is empty. Deletion can be partial and can leave new or concurrent messages. There is no recovery token, automatic reconciliation or atomicity guarantee

Bot credentials satisfy Fluxer's extra authentication checks, called sudo checks, and no extra sudo input is accepted. Fluxer handles attachment removal without guaranteeing physical provider-storage or CDN erasure. The default deadline, rest.defaultTimeoutMs (30,000 ms unless configured), includes capacity and rate-limit waits. Only confirmed HTTP 429 rejection retries, and a 5xx or lost response never causes a replay. After dispatch, the entire enabled message cache is cleared and older pending reads cannot restore it. No gateway events are created locally. Cancellation or closure waits for request cleanup but cannot undo deletion. Options must include confirm: true. Without it, the call fails before any request with reason input and path options.confirm. Input, capacity and HTTP failures use MessageOperationError for deleteOwnMessages

To keep existing files while adding new uploads, include their IDs in attachments. The supplied list replaces the old one. An empty list clears files when nonempty text or embeds remain. Retained file title or description can be replaced or cleared with null. Unknown IDs may be ignored, and a stale list can remove concurrent additions. An attachment:// image or thumbnail URL must match a new image or video upload, not a retained attachment. New uploads use send's copying, attachment source, size, budget and cleanup rules, and inline multipart 429 responses do not replay file or stream sources. Failed edits may leave temporary server data, without physical-erasure guarantees. A flags-only edit is allowed. Omission preserves flags, supplied flags replace only MessageFlags.SuppressEmbeds and MessageFlags.SuppressNotifications, and 0 clears those two bits. Server-managed flags, including the crosspost flags, fail locally before dispatch

Eligible responses can enter the cache. A dispatched edit with an unknown outcome removes the old cached copy. A missing message fails with notFound. A lost response, timeout, cancellation or closure can leave the edit applied. The SDK does not automatically retry edits with unknown outcomes

This is not a complete Guild and never populates community or message caches. No original-message fetch, gateway connection or subscription is required. The auditReason option is not supported

Invalid input, malformed pages, HTTP failures and timeout fail with MessageOperationError for fetchHasReaction. HTTP 404 is notFound. No gateway connection is needed, and cancellation waits for request cleanup

The entire page is validated before returning a frozen array of frozen snapshots. No gateway connection, cache read, automatic traversal or prefetch is required. An empty or short page describes currently accessible results, not necessarily complete history. Pages are separate observations, not a consistent point-in-time snapshot. An enabled cache receives eligible messages oldest first, so tight limits keep the newest

Invalid input, malformed pages or HTTP failures fail with MessageOperationError for fetchHistory, and HTTP 404 remains notFound. The namespace's shared limits, default deadline and bounded read retries apply. Cancellation affects only this request and waits for cleanup, and client closure fails with ClientClosedError

Use nextBefore for the next page and pinnedAt for each pin's time. Page ordering and the before bound use every fractional digit and normalize timezone offsets, while equal instants remain valid. Equal timestamps can repeat messages, so skip duplicate IDs and stop if the cursor does not advance. This call neither traverses further pages nor reads or populates the message cache. Visibility and history permissions can limit the page, so an empty page does not prove there are no pins. Returned messages are snapshots, not live state

The call uses the pins rate limit, the client's default deadline (rest.defaultTimeoutMs, 30,000 ms unless configured) and the namespace's bounded read retries. Invalid input or malformed responses fail with MessageOperationError operation fetchPins, not a partial page. Client closure fails with ClientClosedError, and cancellation affects this request only

An empty reaction produces an empty terminal page. No automatic page traversal, user cache or message cache update is performed. Pages can change between requests, so they are not a stable voter list. This call shares the channel reaction rate limit and the client's default deadline (rest.defaultTimeoutMs, 30,000 ms unless configured), which timeoutMs overrides. The namespace's bounded read retries apply within the original deadline

Invalid input, malformed pages, HTTP failures and timeout fail with MessageOperationError for fetchReactionUsers. HTTP 404 is notFound. Fluxer decides visibility and history access. No gateway connection is needed, and cancellation waits for request cleanup

Fluxer checks source access and destination permissions. This uses send's shared request limits, the client's default deadline (rest.defaultTimeoutMs, 30,000 ms unless configured) and optional destination-message caching. The nonce input follows send's accepted values, generated default and reuse on confirmed rate-limit retries. Fluxer's five-minute duplicate suppression is best effort, not exactly-once delivery. Success follows HTTP, not recipient acknowledgement. A lost response or cancellation can leave the forward posted. Only confirmed rate-limit rejection retries, and no write with an unknown outcome is replayed or rolled back. Expected failures are MessageError or ClientClosedError

The returned Stream reads pages only while it is consumed. Failures end the Stream in its error channel. Interruption waits for request cleanup, and ending consumption releases the buffered page. The Stream uses the caller's services without a separate SDK runtime, and defects keep their Cause, including cleanup failures

The returned Stream reads pages only while it is consumed. Failures end the Stream in its error channel. Interruption waits for request cleanup, and ending consumption releases the buffered page

The returned Stream reads pages only while it is consumed. Failures end the Stream in its error channel. Interruption waits for request cleanup, and ending consumption releases the buffered page

The returned Stream reads pages only while it is consumed. Failures end the Stream in its error channel. Interruption waits for request cleanup, and ending consumption releases the buffered page

The task is an Effect that runs with the caller's services, and its scope, services and errors stay with the caller. A defect in the refresh work joins the task's Cause. Interruption stops and awaits the helper

The users option is required here, because no message identifies an asker. Pass account IDs, or a check such as () => true to let anyone flip. A command context's paginate defaults to the command's author instead. Adding or removing an arrow counts as one click, so only Add Reactions and Read Message History are needed. With removeClicks, only additions count and the bot removes the clicker's arrow after each change, which needs Manage Messages. Clicks are handled one at a time through messages.collectReactions machinery, with its connection requirement, pending-event budget and gateway-loss behavior

Listening stops after idleMs without a click, 60,000 ms by default, and at most timeoutMs after registration, 300,000 ms by default. Cancellation also stops it, as described in the remarks. However it stops, the bot then removes only its own arrows, and the current page stays shown. Each send, edit and reaction request uses the client's default deadline, rate limits and retry rules, and is never replayed after an unknown outcome

A failed page change, arrow or click removal stops listening and returns that failure after the arrows are removed. A users check that throws or returns a non-boolean fails with CollectorError reason filter and is reported to the client-level onError. A failure to remove the arrows is returned after an otherwise normal end, while an earlier failure or cancellation wins over it

Interrupting the Effect stops listening, and interruption completes once the arrows are removed. The Effect completes only after that cleanup. Defects keep their Cause

The auditReason option supplies an optional community audit-log explanation. Fluxer checks channel access and PIN_MESSAGES for community pins. A new pin creates a system message and notifications. An already-pinned message stays unchanged. The pin, unpin and fetchPins methods share the per-channel pins rate limit and the client's request limits. The default deadline is the client's rest.defaultTimeoutMs, 30,000 ms unless configured, and only confirmed HTTP 429 rejections are retried

Expected failures use MessageOperationError operation pin, or ClientClosedError after shutdown. Invalid local input fails with outcome notDispatched. Cancellation or a lost response after sending the request can leave the pin applied. Successful writes and writes with unknown outcomes remove the cached target without guessing its new pinned status. The SDK does not fetch to confirm, create events itself, unpin automatically or roll back the change. The example's steps are separate operations, not a transaction

The result is an in-memory plan with frozen selected messages, usable once by this client only. It cannot be reconstructed from JSON or given to another client. A thrown filter, non-boolean return or promise-like return fails with MessageCleanupError before deletion. A blocking synchronous filter cannot be interrupted. One default deadline, rest.defaultTimeoutMs (30,000 ms unless configured), covers the history scan. Cancellation submits no deletion. No gateway connection or cache reread is needed

Success means publication was accepted and follower delivery was queued, not that every target received a copy. Fluxer sets Crossposted, visible in flags when this client's messageFields selection retains flags. A successful response updates the enabled source-message cache without inserting guessed follower copies. An unknown outcome evicts the cached source. A lost or malformed response is never resent automatically. Cancellation after dispatch cannot establish rollback. No gateway event is awaited and auditReason is not supported

Fluxer checks visibility and history access. For another user, the bot must have authored the message or have MANAGE_MESSAGES in its community. Success follows HTTP 204, whether the reaction was present or already absent, without waiting for or synthesizing events. The call uses addReaction's request limits, deadline, confirmed rate-limit retries and cancellation rules. Expected failures identify removeUserReaction. No reaction cache is changed or retained

After dispatch, cancellation or a lost response can leave the reaction removed, and an unknown outcome is not replayed. The bot cannot restore another user's reaction as that user, and no restoration is attempted

The result is a frozen page or an indexing state. The indexing result means Fluxer accepted the search but is not ready, and the SDK never polls. The caller decides whether and when to search again. Use page numbers from 1 through 400 for later requests, keeping limit unchanged. Fluxer does not honor returned cursors, so the SDK exposes no cursor continuation

Recognized query fields, including inherited and nonenumerable fields, are read and their arrays copied when execution starts. The results and their channel context can change and are not a stable snapshot. Invalid input, POST failure or malformed success fails with MessageOperationError operation search. Search does not use the transient read retries described for this namespace, but confirmed rate-limit handling still applies within the deadline. Cancellation releases only this request

Each attachment uses exactly one source: Bytes in data, a sized Blob or File source, or a finite stream with its exact byte count. Data bytes are copied when execution starts, before any wait. File and stream bytes are read when uploading starts, after upload planning, without copying or spooling. Keep a file source stable while it is read. A finite stream is consumed at most once and must match its declared size. A path string or URL alone is not accepted, and the SDK owns only the readers it acquires

All sources have a 50 MiB per-file maximum and share the client uploads.maxBytes reservation budget. A full upload or request queue fails with busy before copying or reading. Fluxer can impose lower limits. Uploads use presigned planning or an inline multipart fallback. Upload-plan and completion responses have their own 1 MiB limit, and neither response limit caps total memory use. Cleanup releases copied bytes and cancels and releases acquired readers on failure. Failed uploads can leave temporary server data, without a guarantee of physical erasure. Eligible created messages can enter an enabled cache, independently of send completion

The default total deadline, rest.defaultTimeoutMs (30,000 ms unless configured), includes waiting for request capacity and rate limits. The request uses the shared limits and failure rules of this namespace. By default one client admits four REST and upload requests per local shard, up to 64, plus four independent attachment downloads, and both pools share at most 256 pending requests or 4 MiB of pending JSON. The rest client option changes these limits. Only confirmed rate-limit rejections can retry automatically, and sends with unknown outcomes never retry. With inline multipart uploads, a confirmed HTTP 429 can replay copied data bytes only, while file and stream inputs fail with rateLimit instead of being read again

The nonce input can be a 1–32 character string or a nonnegative safe integer. If omitted, the SDK creates one nonce per send execution, and the same nonce is reused for confirmed rate-limit retries. Fluxer tries to suppress duplicate sends for five minutes after saving a message. This does not guarantee that a repeated or concurrent send posts only one message. A lost response or cancellation after dispatch can leave a message posted, and the SDK neither retries nor rolls it back. Check MessageError.outcome before sending again