On This Page

Guilds and Members

77 symbols from @neontechspace/fluxerly/effect

Interfaces#

AuditLogs#

Read a community's audit log as a page or a bounded sequence of entries

Fluxer requires ViewAuditLog. The SDK does not cache audit entries or connect the gateway. Eligible reads retry transient failures at most twice under the shared guild REST policy. Permission, malformed-response and input failures are typed GuildOperationError values. Effects start when executed and preserve the caller's services, unexpected faults and interruption cleanup. Closing clients fail with ClientClosedError. Audit records can change independently. This is not an archival snapshot

interface AuditLogs

fetchPage#

Fetch one filtered audit page with referenced users and webhook metadata that excludes tokens

Supply cursors and filters in AuditLogQuery. A deletion duration that cannot be represented as safe integer milliseconds fails with reason response, without returning a partial page. The returned page is frozen and remains in memory while the caller retains it

fetchPage(
    guildId: string,
    query: AuditLogQuery,
    options?: RequestOptions
): Effect<AuditLogPage, GuildOperationFailure>fetchPage(
  guildId: string,
  query: AuditLogQuery,
  options?: RequestOptions
): Effect<
  AuditLogPage,
  GuildOperationFailure
>

Parameters

guildId
string
options optional
RequestOptions

iterate#

Read filtered audit entries newest first, buffering one page and never prefetching

The maxItems option is required. The pageSize option defaults to 50 and accepts 1–100, maxPages defaults to the pages maxItems needs at pageSize plus 100, and timeoutMs applies to each page. An empty page or maxItems ends the scan, not a short page. Invalid traversal input, a stalled cursor or reaching the page budget fails with PaginationError. Remote failures keep auditLogs.fetchPage's errors. Deletion durations are rounded to whole milliseconds, and one whose milliseconds are not a safe integer fails its page before that page's entries are delivered. Each consumption is independent, and client closure releases the page and fails the next pull. Already delivered entries remain with the caller, and concurrent changes can prevent a complete scan. Use fetchPage instead to also receive referenced users or webhooks

iterate(
    guildId: string,
    query: AuditLogIterationQuery,
    options?: RequestOptions
): Stream<AuditLogEntry, PaginationError | GuildOperationFailure>iterate(
  guildId: string,
  query: AuditLogIterationQuery,
  options?: RequestOptions
): Stream<
  AuditLogEntry,
  | PaginationError
  | GuildOperationFailure
>

Parameters

guildId
string
options optional
RequestOptions

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

Discovery#

Search Fluxer's public community directory or manage a community's listing application

This is separate from instance endpoint discovery. HTTP requests share guild limits and directory data is not cached. Effects start when executed and can be run again, using the caller's services without requiring gateway readiness. The total deadline defaults to the client's rest.defaultTimeoutMs, 30,000 ms unless configured. Reads retry transient transport and HTTP 500/502/503/504 failures at most twice. Writes retry only confirmed 429 rejections. Input, HTTP and malformed-response failures use GuildOperationError. Closing clients use ClientClosedError. Interruption waits for owned cleanup. Defects retain Cause. When the resolved instance reports discoveryEnabled false, search and the application writes fail with reason rejected, HTTP 400 and details.providerCode DISCOVERY_DISABLED. Application writes may publish or unpublish a listing, invalidate guild snapshots and cannot promise rollback. There is no hidden eligibility read, automatic resubmission, review approval or directory-joining operation

interface Discovery

apply#

Submit a community's application to the public directory

ManageGuild, enabled discovery and current Fluxer eligibility are required. An existing pending or approved application fails remotely. Eligible verified or partnered communities may be approved immediately. The returned stored application does not guarantee approval or search visibility. An unknown outcome may already have submitted or published the listing. Check fetchStatus before trying again

apply(
    guildId: string,
    input: DiscoveryApplicationInput,
    options?: RequestOptions
): Effect<DiscoveryApplication, GuildOperationFailure>apply(
  guildId: string,
  input: DiscoveryApplicationInput,
  options?: RequestOptions
): Effect<
  DiscoveryApplication,
  GuildOperationFailure
>

Parameters

guildId
string
options optional
RequestOptions

edit#

Change supplied fields of a pending or approved directory application

ManageGuild and enabled discovery are required. At least one field must be supplied, and omitted fields remain unchanged. Tags use the input type's normalization and replacement rules. No old application is fetched or merged automatically. Updates to an approved listing can become public, while search-index updates can lag or partially fail

edit(
    guildId: string,
    input: DiscoveryApplicationEdit,
    options?: RequestOptions
): Effect<DiscoveryApplication, GuildOperationFailure>edit(
  guildId: string,
  input: DiscoveryApplicationEdit,
  options?: RequestOptions
): Effect<
  DiscoveryApplication,
  GuildOperationFailure
>

Parameters

guildId
string
options optional
RequestOptions

fetchCategories#

Fetch directory category IDs and Fluxer's category labels in provider order

This requires an authenticated client, not membership of a particular community or ManageGuild. No category copy is kept

fetchCategories(
    options?: RequestOptions
): Effect<readonly DiscoveryCategory[], GuildOperationFailure>fetchCategories(
  options?: RequestOptions
): Effect<
  readonly DiscoveryCategory[],
  GuildOperationFailure
>

Parameters

options optional
RequestOptions

fetchStatus#

Fetch a community's current directory eligibility and application state

Use a decimal guild ID with ManageGuild permission. A result with eligible false can mean discovery is disabled or the member threshold is unmet, without distinguishing them. The resolved instance's discoveryEnabled value shows whether discovery is switched on. Eligibility can change before application. Reviewed or removed applications include their available reasons

fetchStatus(
    guildId: string,
    options?: RequestOptions
): Effect<DiscoveryStatus, GuildOperationFailure>fetchStatus(
  guildId: string,
  options?: RequestOptions
): Effect<
  DiscoveryStatus,
  GuildOperationFailure
>

Parameters

guildId
string
options optional
RequestOptions

Fetch one page from the current public community directory

The limit option defaults to 24, and offset defaults to 0. Pages can change between reads, so offset-based scans are not a stable snapshot. This neither joins a community nor caches its directory entry, and needs no gateway connection. Eligible read failures are retried as described for this namespace

search(
    query?: DiscoverySearchQuery,
    options?: RequestOptions
): Effect<DiscoverySearchPage, GuildOperationFailure>search(
  query?: DiscoverySearchQuery,
  options?: RequestOptions
): Effect<
  DiscoverySearchPage,
  GuildOperationFailure
>

Parameters

query optional
DiscoverySearchQuery
options optional
RequestOptions

withdraw#

Withdraw a pending application or remove an approved directory listing

ManageGuild and enabled discovery are required. HTTP 204 succeeds with no value. A missing application is a remote error, not an assumed successful no-op. Fluxer removes the application record and may separately remove its feature or search entry. The community and its members remain, and the prior application is not restored. An unknown or partial outcome needs remote inspection and may require operator recovery, not blind replay

withdraw(
    guildId: string,
    options?: RequestOptions
): Effect<void, GuildOperationFailure>withdraw(
  guildId: string,
  options?: RequestOptions
): Effect<
  void,
  GuildOperationFailure
>

Parameters

guildId
string
options optional
RequestOptions

Guilds#

Read or change guilds and obtain gateway counts

A guild is a Fluxer community. HTTP methods return Effects and do not require a gateway connection. The REST rules below exclude fetchCounts, which requires gateway readiness and has its own documented contract

interface Guilds

Requests share the client's REST or upload slots across all assigned shards, four per local shard by default, up to 64 (rest.concurrency). Attachment-download slots are separate, four by default (rest.mediaConcurrency). Both pools together allow 256 waiting requests or 4 MiB of queued JSON by default (rest.maxQueued and rest.queuedJsonMaxBytes)

The total deadline defaults to the client's rest.defaultTimeoutMs, 30,000 ms unless configured, including waits. Reads retry transport failures and HTTP 500/502/503/504 at most twice. Retry delays are 125–250 ms, then 250–500 ms, or a longer valid Retry-After. Confirmed HTTP 429 waits are separate and never reset the deadline

Input, 404, permission failures and malformed successes do not retry. Expected failures use GuildOperationError

Successful REST JSON responses are limited to 16 MiB before parsing. This is not a total memory limit. Oversized responses fail with reason response and do not retry. If a response fails after a write was sent, the write may still have applied. The SDK does not assume rollback

Interruption awaits owned cleanup. Closing clients use ClientClosedError. Defects retain Cause, including cleanup failures

deleteOwnMessages#

Irreversibly delete this bot's entire authored message history across one community

Use a decimal guild ID. Other authors' messages are preserved, and the bot stays in the community with the same roles

deleteOwnMessages(
    guildId: string,
    options: OwnMessageDeletionOptions
): Effect<void, GuildOperationFailure>deleteOwnMessages(
  guildId: string,
  options:
    OwnMessageDeletionOptions
): Effect<
  void,
  GuildOperationFailure
>

Success follows Fluxer's empty HTTP 202 response, not a completed-job report, deletion count or gateway event. The community may still contain new or concurrent messages. Deletion can be partial and is not atomic. There is no recovery token or automatic reconciliation

Bot credentials satisfy Fluxer's extra authentication checks, called sudo checks. No extra sudo fields or audit reason are 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 GuildOperationError for guilds.deleteOwnMessages

Parameters

guildId
string
TypeScript
import type { Client } from "@neontechspace/fluxerly/effect"
export const deleteOwnMessagesExample = (client: Client, channelId: string) =>
    client.messages.deleteOwnMessages(channelId, { confirm: true })
export const deleteOwnGuildMessagesExample = (client: Client, guildId: string) =>
    client.guilds.deleteOwnMessages(guildId, { confirm: true })

edit#

Change only supplied community settings that a bot may edit

Omitted fields remain unchanged, and no old settings are fetched or merged automatically

edit(
    guildId: string,
    input: GuildEdit,
    options?: AuditedRequestOptions
): Effect<Guild, GuildOperationFailure>edit(
  guildId: string,
  input: GuildEdit,
  options?: AuditedRequestOptions
): Effect<
  Guild,
  GuildOperationFailure
>

ManageGuild is required. Fluxer checks feature restrictions and constraints beyond local GuildEdit validation. Success returns the server's observed configuration, not gateway acknowledgement. Shared guild write deadlines and cancellation cleanup apply. Dispatched writes invalidate cached guild data even when the outcome is unknown. After a lost response, fetch before deciding to retry. No rollback is guaranteed

Parameters

guildId
string
input
GuildEdit
options optional
AuditedRequestOptions

editVanityUrl#

Set a community's custom invite code, replace it, or pass null to remove it

The code must already be lowercase, 2–32 ASCII letters or digits with single internal hyphens. No automatic normalization is performed

editVanityUrl(
    guildId: string,
    code: string | null,
    options?: AuditedRequestOptions
): Effect<GuildVanityUrl, GuildOperationFailure>editVanityUrl(
  guildId: string,
  code: string | null,
  options?: AuditedRequestOptions
): Effect<
  GuildVanityUrl,
  GuildOperationFailure
>

ManageGuild is required. Setting a code also requires the community's VANITY_URL feature. Reserved or taken codes fail remotely. Changing a code releases the old code and starts a new use count, and reclaiming the old code is not guaranteed. Success returns the code and URL without a hidden use-count read, access check or gateway acknowledgement

Shared guild deadlines and cleanup apply. Only confirmed HTTP 429 rejection retries, and dispatched writes invalidate guild snapshots. After an unknown outcome, call fetchVanityUrl before deciding how to recover. Provider-side partial changes may need operator recovery and are not rolled back automatically

Parameters

guildId
string
code
string | null
options optional
AuditedRequestOptions

fetch#

Fetch a community's identity and settings by decimal ID

Fluxer requires membership. The result is a frozen snapshot. This does not fetch or keep nested members, roles or channels, or infer counts or completeness

fetch(
    guildId: string,
    options?: RequestOptions
): Effect<Guild, GuildOperationFailure>fetch(
  guildId: string,
  options?: RequestOptions
): Effect<
  Guild,
  GuildOperationFailure
>

Parameters

guildId
string
options optional
RequestOptions

fetchCounts#

Request fresh, visibility-filtered counts for 1–100 communities over the connected gateway

Use distinct positive decimal IDs without leading zeros, no greater than "9223372036854775807". The IDs are copied when execution starts. Every community must belong to a ready shard assigned to this client. An unassigned or unready shard fails with notConnected, not an omitted result. The result contains frozen counts and omittedGuildIds in requested order. An omitted entry is unavailable, not zero, and does not explain why it is missing. Community counts are separate observations, not one consistent snapshot. A missing whole reply fails with timeout

fetchCounts(
    guildIds: readonly string[],
    options?: RequestOptions
): Effect<GuildCountsResult, CountOperationFailure>fetchCounts(
  guildIds: readonly string[],
  options?: RequestOptions
): Effect<
  GuildCountsResult,
  CountOperationFailure
>

One call uses one of four client-wide gateway request slots until all shard commands and replies finish. The channels.fetchMemberCounts and members.iterateChunks methods share those slots. There is no waiting queue for request slots, so excess calls fail with busy. Commands may wait for gateway pacing, and a full internal command queue also fails with busy. The default 30,000 ms deadline includes registration, commands and all reply fragments. Cancellation or deadline expiry withdraws unsent commands and immediately releases local request capacity. Fluxer also limits member and presence work, so a local slot does not guarantee a reply. Only a gateway gap on a participating shard fails with connectionLost, and late replies are ignored. No REST fallback, connection, caching, polling or retries are performed. Expected failures use CountOperationError or ClientClosedError

Parameters

guildIds
readonly string[]
options optional
RequestOptions

The Effect uses the caller's services. Interruption waits for local cleanup but cannot cancel work already sent to Fluxer, and defects keep their Cause

TypeScript
import { Effect } from "effect"
import type { Client } from "@neontechspace/fluxerly/effect"
export function countsExample(client: Client, guildId: string, channelId: string) {
    return Effect.gen(function* () {
        const guilds = yield* client.guilds.fetchCounts([guildId])
        const channels = yield* client.channels.fetchMemberCounts(guildId, [channelId])
        return { guilds, channels }
    })
}

fetchPage#

Fetch one page of communities this bot belongs to, ordered by ascending guild ID

The limit option defaults to 200 and accepts 1–200. Choose either before or after, not both. Those cursors refer to existing memberships, and if a cursor community was removed, Fluxer may restart the page. The withCounts option defaults to false. Permission bits or requested approximate counts may be omitted, and an omitted value means unavailable, not zero. The frozen summaries do not read or populate the guild cache. No gateway connection or further page traversal is performed. Shared guild deadlines, retries and failures apply. This page is not a complete membership inventory or proof of matching gateway state

fetchPage(
    query?: GuildListQuery,
    options?: RequestOptions
): Effect<readonly GuildListSummary[], GuildOperationFailure>fetchPage(
  query?: GuildListQuery,
  options?: RequestOptions
): Effect<
  readonly GuildListSummary[],
  GuildOperationFailure
>

Parameters

query optional
GuildListQuery
options optional
RequestOptions
TypeScript
import { Effect } from "effect"
import type { Client } from "@neontechspace/fluxerly/effect"
export const guildListExample = (client: Client) =>
    client.guilds.fetchPage({ withCounts: true }).pipe(
        Effect.map(page => page.map(({ id, permissions, approximateMemberCount }) => ({ id, permissions, approximateMemberCount }))),
    )

fetchVanityUrl#

Fetch a community's custom invite code, URL and use count with ManageGuild permission

A null code and URL means the community has no custom invite. The read is remote, without a vanity cache or gateway connection. Shared guild read retries, deadline, cancellation and failure rules apply

fetchVanityUrl(
    guildId: string,
    options?: RequestOptions
): Effect<GuildVanityUrlUsage, GuildOperationFailure>fetchVanityUrl(
  guildId: string,
  options?: RequestOptions
): Effect<
  GuildVanityUrlUsage,
  GuildOperationFailure
>

Parameters

guildId
string
options optional
RequestOptions

get#

Look up a community in the enabled guild cache, without a request or gateway connection

The result is undefined when caching is disabled or the entry is absent, expired or evicted. Cached data may be stale, so use fetch for a remote read. A hit becomes more recently used without extending expiry. An invalid ID is misuse: The default API throws GuildOperationError with reason input and the native API dies with it. A closing or closed client has no cache, so the result is undefined

get(guildId: string): Effect<Guild | undefined>get(
  guildId: string
): Effect<Guild | undefined>

Parameters

guildId
string
Returns
Effect<Guild | undefined>

iterate#

Read the bot's community memberships in ascending ID order, retaining one page and never prefetching

The maxItems option is required. The pageSize option defaults to 200, maxPages defaults to the pages maxItems needs at pageSize plus 100, and timeoutMs applies to each page. Iteration ends at maxItems or an empty page, not a short page. A repeated or backward ID after a removed cursor fails with PaginationError cursorStalled before delivering that page. Other traversal failures are input and pageLimit, and remote failures keep fetchPage's error. Each consumption copies inputs independently. Client closure releases the page and fails the next pull. The withCounts option applies to every page, but missing permission bits or counts remain unavailable, not zero. No gateway connection or cache fill is needed. Already delivered communities remain with the caller, and separate pages do not guarantee a consistent inventory

iterate(
    query: GuildIterationQuery,
    options?: RequestOptions
): Stream<GuildListSummary, PaginationError | GuildOperationFailure>iterate(
  query: GuildIterationQuery,
  options?: RequestOptions
): Stream<
  GuildListSummary,
  | PaginationError
  | GuildOperationFailure
>

Parameters

options optional
RequestOptions

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

TypeScript
import type { Client } from "@neontechspace/fluxerly/effect"
export function guildMembershipsExample(client: Client) {
    return client.guilds.iterate({ maxItems: 1000 })
}

leave#

Remove this bot from one community while preserving its authored messages

HTTP 204 completes the removal, without waiting for a gateway event. The client remains usable for other communities

leave(
    guildId: string,
    options?: RequestOptions
): Effect<void, GuildOperationFailure>leave(
  guildId: string,
  options?: RequestOptions
): Effect<
  void,
  GuildOperationFailure
>

Fluxer rejects owners or restricted memberships. Only confirmed HTTP 429 rejection retries. A lost response or cancellation can leave membership removed. Check fetch or the membership list to resolve an unknown outcome. Rejoining needs separate authorization

Successful writes and writes with unknown outcomes invalidate cached guild resources and conflicting pending reads. A confirmed leave also forgets this client's selected member presences, while an unknown outcome keeps that selection. Any dispatched attempt removes this community's cached channels and clears the message cache, because messages need not identify their community. Objects already returned to the caller stay unchanged. This neither deletes the community nor shuts down the client

Parameters

guildId
string
options optional
RequestOptions

MemberChunkOptions#

Set how long a member stream can run and how many unread bytes it can hold

The SDK checks and copies these settings when consumption starts, not when the iterator or native Stream is created. One client admits one member stream across its local shards, sharing four request slots with count calls. It sends at most 12 member requests in any 11 seconds, keeping under Fluxer's limit of 12 per account in 10 seconds. The children of one supervisor keep that count together. Ending the stream early releases the SDK's local request slot but cannot stop work Fluxer has already started

interface MemberChunkOptions
maxPendingBytes optional#

Maximum source-JSON bytes counted for unread batches, a positive safe integer, default 4,194,304 (4 MiB)

Includes a single batch delivered directly to a waiting reader. Overflow fails rather than dropping batches. This bounds the SDK's batch byte accounting, not total JavaScript heap, decoding overhead or caller-held batches

number
timeoutMs optional#

Total milliseconds from dispatch until the final batch arrives, integer 1–2,147,483,647, default 30,000

Pausing consumption does not pause this deadline or the provider. No timeout applies after the full response arrives

number

Members#

Read community members, change their roles and nicknames, or perform moderation actions including bans

HTTP methods return Effects and use the same concurrency limits, deadlines and error rules as Guilds. The iterateChunks method uses the gateway and its own documented Stream rules instead

interface Members

Returned members are frozen snapshots. ClientOptions.cache.members can retain them, but does not predict permissions or download a whole community

Writes retry only confirmed 429 rejections, never unknown outcomes. Interruption cannot undo a write request already sent. The setRoles, editSelf, setNickname, addRole and removeRole methods accept AuditedRequestOptions. Member reads and searches reject auditReason. Moderation methods retain their more specific audited option types

addRole#

Grant one role to a member without replacing their other roles

Use a decimal role ID, excluding the implicit everyone role. Fluxer requires ManageRoles and checks hierarchy. HTTP 204 succeeds with no value, not an event acknowledgement or proof the role was previously absent. Fluxer currently accepts auditReason on member-role add and remove routes without retaining it in an audit entry. The example collects one future reaction addition before assigning the role. It needs a connected client, an existing message in this community and a role the bot can assign, and a timeout can collect nothing. It is not a persistent reaction-role system and does not revoke roles on removal

addRole(
    member: MemberReference,
    roleId: string,
    options?: AuditedRequestOptions
): Effect<void, GuildOperationFailure>addRole(
  member: MemberReference,
  roleId: string,
  options?: AuditedRequestOptions
): Effect<
  void,
  GuildOperationFailure
>

Parameters

roleId
string
options optional
AuditedRequestOptions
TypeScript
import { Effect } from "effect"
import type { Client, MessageReference } from "@neontechspace/fluxerly/effect"
export const assignRoleExample = (client: Client, message: MessageReference, guildId: string, roleId: string) => Effect.scoped(
    Effect.gen(function* () {
        const collector = yield* client.messages.collectReactions(message, {
            emoji: "✅",
            onReaction: reaction => client.members.addRole({ guildId, userId: reaction.userId }, roleId),
        })
        return yield* collector.result()
    }),
)

ban#

Ban a user from a community, including a user who is not currently a member

Pass decimal guildId and userId. The default ban is permanent and deletes no messages. Fluxer requires BanMembers and checks role hierarchy. In a community whose mfaLevel is GuildMfaLevels.Elevated, the call fails with reason rejected, HTTP 400 and apiError.code twoFactorRequired, unless the bot owns the community or its application owner has two-factor authentication enabled. HTTP 204 succeeds with no value, without waiting for an event

ban(
    target: MemberReference,
    input?: BanInput,
    options?: AuditedRequestOptions
): Effect<void, GuildOperationFailure>ban(
  target: MemberReference,
  input?: BanInput,
  options?: AuditedRequestOptions
): Effect<
  void,
  GuildOperationFailure
>

Only confirmed HTTP 429 rejection retries. A dispatched failure can leave the ban or queued message deletion applied. Dispatched actions invalidate the cached member even on rejection. When deleteMessagesMs is above 0, the user's cached messages are removed from every community, because cached messages need not carry a guild ID. The deletion job can finish later, so a later cache hit does not prove a message survived

Fluxer bans can also block rejoining through IP or email checks. Unbanning restores neither deleted messages nor membership. Shared guild deadlines, failures and cleanup apply, and cancellation cannot undo a dispatched ban

Parameters

input optional
BanInput
options optional
AuditedRequestOptions

clearTimeout#

Clear a member's timeout and return the HTTP member snapshot

This sends null rather than a negative duration. The timeout method's permissions, deadline, execution, cache and failure rules apply. No gateway event is awaited

clearTimeout(
    target: MemberReference,
    options?: TimeoutOptions
): Effect<GuildMember, GuildOperationFailure>clearTimeout(
  target: MemberReference,
  options?: TimeoutOptions
): Effect<
  GuildMember,
  GuildOperationFailure
>

Parameters

options optional
TimeoutOptions

disconnect#

Disconnect one observed voice connection, or all active connections if target.connectionId is omitted

MoveMembers is required. The returned member follows HTTP, without waiting for voiceStateUpdate. A repeated call can fail because the member is no longer connected. The move method's deadline, audit, permission and cache rules apply. An unknown outcome needs later observations rather than blind replay

disconnect(
    target: VoiceConnectionReference,
    options?: AuditedRequestOptions
): Effect<GuildMember, GuildOperationFailure>disconnect(
  target: VoiceConnectionReference,
  options?: AuditedRequestOptions
): Effect<
  GuildMember,
  GuildOperationFailure
>

Parameters

options optional
AuditedRequestOptions

editSelf#

Change this bot's community profile, not its global account or another member

Omitted fields stay unchanged, and null clears an override. An empty input or unknown key fails locally. Fluxer checks permissions and field-specific rate limits. Avatar, banner, bio and accentColor can be silently ignored without the community-profile entitlement. The returned member excludes bio and pronouns, so success does not prove those fields were stored. Writes with unknown outcomes or cancellation remove the affected cache entry. A definite rejection preserves the old snapshot

editSelf(
    guildId: string,
    input: MemberProfileEdit,
    options?: AuditedRequestOptions
): Effect<GuildMember, GuildOperationFailure>editSelf(
  guildId: string,
  input: MemberProfileEdit,
  options?: AuditedRequestOptions
): Effect<
  GuildMember,
  GuildOperationFailure
>

Parameters

guildId
string
options optional
AuditedRequestOptions

fetch#

Fetch one community member by decimal guildId and userId

A missing member fails with reason notFound rather than an empty result

fetch(
    member: MemberReference,
    options?: RequestOptions
): Effect<GuildMember, GuildOperationFailure>fetch(
  member: MemberReference,
  options?: RequestOptions
): Effect<
  GuildMember,
  GuildOperationFailure
>

Parameters

options optional
RequestOptions

fetchBans#

Fetch a community's current full ban list with BanMembers permission

Results are frozen. There is no ban cache, pagination or guaranteed order. Separate reads are not one consistent snapshot. Shared guild deadlines and read retries apply. A malformed response fails rather than producing a partial list

fetchBans(
    guildId: string,
    options?: RequestOptions
): Effect<readonly GuildBan[], GuildOperationFailure>fetchBans(
  guildId: string,
  options?: RequestOptions
): Effect<
  readonly GuildBan[],
  GuildOperationFailure
>

Parameters

guildId
string
options optional
RequestOptions

fetchCanManage#

Check whether the bot, or the member named by options.actorUserId, is above a target member in the community's role hierarchy

Pass actorUserId to check a moderator who ran a command, such as { actorUserId: message.author.id }. The helper fetches fresh guild, actor member, target member and role data in parallel, then applies hierarchy.canManage. One default deadline, rest.defaultTimeoutMs (30,000 ms unless configured), covers those reads. Failure or cancellation waits for sibling request cleanup. No cache is read first and no helper result is retained, but underlying reads can still populate enabled resource caches. A true result covers only hierarchy using four separate observations that may change before an action. It does not check permission bits or MFA, authorize an action or perform it

fetchCanManage(
    target: MemberReference,
    options?: CanManageOptions
): Effect<boolean, GuildOperationFailure>fetchCanManage(
  target: MemberReference,
  options?: CanManageOptions
): Effect<
  boolean,
  GuildOperationFailure
>

Parameters

options optional
CanManageOptions
Returns
Effect<boolean, GuildOperationFailure>
TypeScript
import type { Client } from "@neontechspace/fluxerly/effect"
export const canManageExample = (client: Client, guildId: string, userId: string) =>
    client.members.fetchCanManage({ guildId, userId })

fetchPage#

Fetch one page of members ordered by ascending user ID

The limit option defaults to 100 and accepts 1–1,000. Use the last returned userId as after for another page. Inputs are copied when execution starts. A malformed page fails as a whole. An empty page ends a scan, but no hasMore guarantee or automatic traversal is provided. Separate pages are not one consistent membership snapshot

fetchPage(
    guildId: string,
    query?: MemberQuery,
    options?: RequestOptions
): Effect<readonly GuildMember[], GuildOperationFailure>fetchPage(
  guildId: string,
  query?: MemberQuery,
  options?: RequestOptions
): Effect<
  readonly GuildMember[],
  GuildOperationFailure
>

Parameters

guildId
string
query optional
MemberQuery
options optional
RequestOptions

fetchSelf#

Fetch this bot's membership in a community without knowing its user ID

No gateway READY event or connection is required

fetchSelf(
    guildId: string,
    options?: RequestOptions
): Effect<GuildMember, GuildOperationFailure>fetchSelf(
  guildId: string,
  options?: RequestOptions
): Effect<
  GuildMember,
  GuildOperationFailure
>

Parameters

guildId
string
options optional
RequestOptions

get#

Look up a community member by decimal guildId and userId in the enabled cache, without a request

Enable cache.members to retain members, and cache.roles for local role-name lookup. Explicit fetches or later gateway events can fill those caches, including the author or actor member that Fluxer attaches to message, reaction and typing events, so a member who just spoke can be present without a request. The cache misses, stale-snapshot warnings, misuse and recency rules of guilds.get apply. The example makes no requests when rendering observed role names. A missing member gives undefined, and missing role names fall back to IDs. Observed names are not effective permissions or proof of a complete role list

get(member: MemberReference): Effect<GuildMember | undefined>get(
  member: MemberReference
): Effect<GuildMember | undefined>

Parameters

Returns
Effect<GuildMember | undefined>
TypeScript
import { Effect } from "effect"
import type { Client, MemberReference } from "@neontechspace/fluxerly/effect"
export const cachedRoleNamesExample = (client: Client, target: MemberReference) => Effect.gen(function* () {
    const member = yield* client.members.get(target)
    if (!member) return undefined
    return yield* Effect.forEach(member.roleIds, id =>
        client.roles.get({ guildId: target.guildId, id }).pipe(Effect.map(role => role?.name ?? id)))
})

getSelf#

Look up this bot's own membership of a community by decimal guildId in the enabled member cache, without a request

The result is undefined while the bot's account ID is unknown, which READY or a successful members.fetchSelf supplies, and when cache.members is off or the member is not cached. Each guildCreate event stores the bot's own member. Those sent while a session starts list it by account ID only, and the SDK completes it from READY's account. Successful members.fetchSelf and members.fetch reads and member events store it too. The cache misses, stale-snapshot warnings and recency rules of guilds.get apply. An invalid ID is misuse: The default API throws GuildOperationError with reason input and the native API dies with it. A closing or closed client has no cache, so the result is undefined

getSelf(guildId: string): Effect<GuildMember | undefined>getSelf(
  guildId: string
): Effect<GuildMember | undefined>

Parameters

guildId
string
Returns
Effect<GuildMember | undefined>

iterate#

Read community members by ascending user ID, without connecting the gateway or downloading the community eagerly

The maxItems option is required, and pageSize defaults to 100, and maxPages defaults to the pages maxItems needs at pageSize plus 100. Each consumption copies inputs and keeps one page, requested only when needed. An empty page or maxItems ends the scan, not a short page. The timeoutMs option applies to each fetchPage call. Remote failures keep that method's error and read retry policy. PaginationError covers input, cursorStalled and pageLimit. Client closure releases the page and fails the next pull with ClientClosedError. Delivered members remain with the caller, and an enabled cache can receive page members. No roles or permission decisions are fetched. Separate pages are not a consistent membership snapshot

iterate(
    guildId: string,
    query: UserIterationQuery,
    options?: RequestOptions
): Stream<GuildMember, PaginationError | GuildOperationFailure>iterate(
  guildId: string,
  query: UserIterationQuery,
  options?: RequestOptions
): Stream<
  GuildMember,
  | PaginationError
  | GuildOperationFailure
>

Parameters

guildId
string
options optional
RequestOptions

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

TypeScript
import { Stream } from "effect"
import type { Client } from "@neontechspace/fluxerly/effect"
export const paginationMembersExample = (client: Client, guildId: string) =>
    client.members.iterate(guildId, { maxItems: 1000 }).pipe(
        Stream.filter(member => !member.isBot), Stream.take(1), Stream.runCollect,
    )

iterateChunks#

Request one community's members over the gateway and deliver frozen batches without accumulating a roster

Choose explicit userIds, a case-insensitive nickname, global-name or username prefix, or all: true. The community and explicit user IDs must be positive decimal strings without leading zeros, no greater than 9223372036854775807. This gateway prefix query is separate from REST member search. Each consumption copies the input and sends one request. The community must have a ready shard assigned to this client, otherwise the request fails with notConnected. Full-list mode is capped by Fluxer at 100,000 members, and Fluxer's server-enforced 30-second limit per bot and community also applies. Only one member stream runs per client, and it uses one of four client-wide gateway slots shared with counts until consumed or released. A full request-slot budget or internal command queue fails with MemberChunkError reason busy. Only a gap on this community's shard ends the stream, while work on healthy shards continues. No connection, REST fallback, cache fill, presence subscription, raw-event forwarding or retries are added

iterateChunks(
    guildId: string,
    query: MemberChunkQuery,
    options?: MemberChunkOptions
): Stream<MemberChunk, MemberChunkFailure>iterateChunks(
  guildId: string,
  query: MemberChunkQuery,
  options?: MemberChunkOptions
): Stream<
  MemberChunk, MemberChunkFailure
>

Fluxer accepts 12 member requests per account in 10 seconds and drops the rest without an answer. The SDK therefore sends at most 12 from one client in any 11 seconds and fails a further request at once with reason rateLimit and retryAfterMs, without sending it. A member request sent with gateway.send counts as well, but gateway.send never refuses one. The children of one supervisor share one count through their parent. A child that gets no answer from the parent within one second counts only its own requests and logs supervisor.memberRequestsLocal once. The count leaves out requests from other processes with the same token, and the SDK does not track Fluxer's limit of 40 requests per community in 10 seconds across all accounts. A request Fluxer drops in either case ends with reason timeout

Batches are frozen and follow provider chunk order. The SDK checks batch indices, advertised batch count, unique members and matching presence data. Successful completion means all advertised batches arrived, not a complete or atomic guild snapshot. Missing selected user IDs are listed on the final batch. Optional presence data can omit unavailable, offline or invisible users, so omission does not prove offline status

The timeoutMs option defaults to 30,000 for the whole reply, including waits for gateway pacing. Cancellation, deadline expiry or ending consumption withdraws an unsent request and releases its local slot. A request already sent to Fluxer cannot be withdrawn. The maxPendingBytes option defaults to 4 MiB of source-JSON bytes counted for unread gateway batches. This bounds the SDK's byte accounting, not total memory use. Fluxer sends batches without waiting for the reader, so slow readers can overflow. Pausing consumption does not pause intake or the deadline

Gateway loss, timeout, malformed replies or overflow drop unread batches and end with one MemberChunkError, never a silent partial success. Already delivered batches remain with the caller. Client closure releases buffers and fails with ClientClosedError. Local cleanup cannot cancel Fluxer's dispatched work. Late replies are ignored and Resume does not replay batches

Parameters

guildId
string
options optional
MemberChunkOptions

The Stream runs in the consuming Effect's scope and services. Interruption, early termination and scope closure release intake, timers and buffers. Defects and interruption keep their Cause

TypeScript
import { Effect, Stream } from "effect"
import type { Client, MemberChunk } from "@neontechspace/fluxerly/effect"
export function memberChunksExample(client: Client, guildId: string, handleBatch: (chunk: MemberChunk) => Effect.Effect<void>) {
    return client.members.iterateChunks(guildId, { all: true, presences: true }).pipe(
        Stream.runForEach(handleBatch)
    )
}

iterateSearch#

Read unique indexed member-search hits with a bounded scan

The maxItems option is required. The pageSize option defaults to 100 and accepts 1–100, and maxPages defaults to the pages maxItems needs at pageSize plus 100. Each consumption copies filters and their arrays, including recognized inherited and nonenumerable fields, and keeps independent state. Pages are requested only as needed, without prefetch or full-member fetches

iterateSearch(
    guildId: string,
    filters: Omit<MemberSearchQuery, "limit">,
    limits: MemberSearchIterationLimits,
    options?: RequestOptions
): Stream<MemberSearchHit, PaginationError | GuildOperationFailure>iterateSearch(
  guildId: string,
  filters: Omit<
    MemberSearchQuery, "limit"
  >,
  limits:
    MemberSearchIterationLimits,
  options?: RequestOptions
): Stream<
  MemberSearchHit,
  | PaginationError
  | GuildOperationFailure
>

Offset advances by the number of hits received. Each user is emitted at most once, keeping at most maxItems IDs to skip duplicates. Index changes can still skip users, so the result is not a complete or consistent membership snapshot. A page with indexing true fails the scan with PaginationError reason indexing instead of ending it early. An empty page before the observed total fails with cursorStalled. Reaching maxItems is normal completion, not exhaustion. Input, pageLimit and cursorStalled are other PaginationError reasons. Each page uses search's timeout, permission precheck, retry and cache rules. Client closure releases retained state, and delivered hits remain with the caller

Parameters

guildId
string
filters
Omit<MemberSearchQuery, "limit">
options optional
RequestOptions

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

kick#

Remove a member from the community, succeeding with no value after HTTP 204

Fluxer requires KickMembers and checks hierarchy. In a community whose mfaLevel is GuildMfaLevels.Elevated, the call fails with reason rejected, HTTP 400 and apiError.code twoFactorRequired, unless the bot owns the community or its application owner has two-factor authentication enabled. This does not ban the user, restore membership automatically or wait for a removal event. Missing membership is an API error. Dispatched actions invalidate the member cache even on rejection. The timeout method's execution, deadline and failure rules apply. Writes with unknown outcomes are not replayed

kick(
    target: MemberReference,
    options?: AuditedRequestOptions
): Effect<void, GuildOperationFailure>kick(
  target: MemberReference,
  options?: AuditedRequestOptions
): Effect<
  void,
  GuildOperationFailure
>

Parameters

options optional
AuditedRequestOptions

move#

Move a member who is already in voice to a positive decimal voice-channel ID

The target.connectionId value selects one observed connection. Omit it to move every active connection for that member. Fluxer requires MoveMembers and checks hierarchy, destination visibility and permission to connect. Fluxer refuses a move into an occupied voice channel whose participants all use peer-to-peer voice, and the member stays in its current channel. The call then fails with reason rejected, HTTP 400 and details.providerCode USER_NOT_IN_VOICE even though the member is in voice. A retry fails the same way while the destination stays in peer-to-peer mode. The frozen HTTP member result means Fluxer accepted the move, not that the participant has reconnected. A voiceStateUpdate event can first show channelId null, then a new connection ID in the destination. Shared moderation deadlines, auditReason validation, confirmed HTTP 429 retries and member-cache invalidation apply. A lost response or cancellation can leave the move applied. Inspect later observations rather than retrying blindly

move(
    target: VoiceConnectionReference,
    channelId: string,
    options?: AuditedRequestOptions
): Effect<GuildMember, GuildOperationFailure>move(
  target: VoiceConnectionReference,
  channelId: string,
  options?: AuditedRequestOptions
): Effect<
  GuildMember,
  GuildOperationFailure
>

Parameters

channelId
string
options optional
AuditedRequestOptions
TypeScript
import type { Client, VoiceConnectionReference } from "@neontechspace/fluxerly/effect"
export const moveVoiceConnection = (client: Client, target: VoiceConnectionReference, channelId: string) =>
    client.members.move(target, channelId, { auditReason: "Moved to support" })

removeRole#

Remove one role from a member while leaving other roles unchanged

The addRole method's permissions and completion rules apply. The SDK sends the request even if a local snapshot lacks the role. Success does not prove the role was previously assigned

removeRole(
    member: MemberReference,
    roleId: string,
    options?: AuditedRequestOptions
): Effect<void, GuildOperationFailure>removeRole(
  member: MemberReference,
  roleId: string,
  options?: AuditedRequestOptions
): Effect<
  void,
  GuildOperationFailure
>

Parameters

roleId
string
options optional
AuditedRequestOptions

Search Fluxer's member index for a community, without using or populating the member cache

Without filters, this reads 25 members from offset 0, ordered by newest join time first. Recognized fields, including inherited and nonenumerable fields, are read and filter arrays copied when execution starts. Results can lag membership changes. A result with indexing true means the index is still being built, not that no members matched. An empty result with indexing false can still mean Fluxer's search service is unavailable. Counts do not guarantee completeness, and hits do not trigger full-member fetches

search(
    guildId: string,
    filters?: MemberSearchQuery,
    options?: RequestOptions
): Effect<MemberSearchPage, GuildOperationFailure>search(
  guildId: string,
  filters?: MemberSearchQuery,
  options?: RequestOptions
): Effect<
  MemberSearchPage,
  GuildOperationFailure
>

Fluxer requires at least one of ManageGuild, ManageRoles, ManageNicknames, BanMembers, ModerateMembers or KickMembers. While Guild.mfaLevel is GuildMfaLevels.Elevated, holding any of these except ManageNicknames can make Fluxer reject every search, including one without filters, with HTTP 400 and apiError.code twoFactorRequired, as described on Guild.mfaLevel

Join-source and invite filters first fetch the bot's community permissions and require ManageGuild. The three independent precheck reads run concurrently under the same total deadline, and a failure cancels sibling reads. When the precheck finds ManageGuild missing, the call fails with reason rejected, outcome notDispatched and no HTTP status. The precheck prevents knowingly sending ignored filters, but permissions can still change before search. Other queries have no hidden reads. The default deadline, rest.defaultTimeoutMs (30,000 ms unless configured), covers the whole call, including that precheck. Precheck GETs use eligible read retries. Search POST retries only confirmed HTTP 429 rejection because it may queue indexing. Expected failures use GuildOperationError or ClientClosedError

Parameters

guildId
string
filters optional
MemberSearchQuery
options optional
RequestOptions

setDeaf#

Set or clear the community deafen flag for a member currently connected to voice

Pass { deafened: true } to deafen or { deafened: false } to undeafen. Fluxer requires DeafenMembers and checks hierarchy. The returned member contains isDeafened, without waiting for a voice event. This does not control self-deafen or connect the bot to voice. The move method's deadline, audit, retry, cancellation and member-cache rules apply

setDeaf(
    target: MemberReference,
    input: VoiceDeafenInput,
    options?: AuditedRequestOptions
): Effect<GuildMember, GuildOperationFailure>setDeaf(
  target: MemberReference,
  input: VoiceDeafenInput,
  options?: AuditedRequestOptions
): Effect<
  GuildMember,
  GuildOperationFailure
>

Parameters

options optional
AuditedRequestOptions

setMute#

Set or clear the community mute flag for a member currently connected to voice

Pass { muted: true } to mute or { muted: false } to unmute. Fluxer requires MuteMembers and checks hierarchy. The returned member contains isMuted, without waiting for a voice event. This does not control self-mute or connect the bot to voice. The move method's deadline, audit, retry, cancellation and member-cache rules apply

setMute(
    target: MemberReference,
    input: VoiceMuteInput,
    options?: AuditedRequestOptions
): Effect<GuildMember, GuildOperationFailure>setMute(
  target: MemberReference,
  input: VoiceMuteInput,
  options?: AuditedRequestOptions
): Effect<
  GuildMember,
  GuildOperationFailure
>

Parameters

options optional
AuditedRequestOptions

setNickname#

Set one member's nickname, or pass null to clear it

A raw empty string fails, while a nonempty string containing only trim whitespace is accepted as Fluxer's clear value. Otherwise, validation removes U+000C and U+202E, trims surrounding whitespace, and requires 1–32 UTF-16 code units. The original string is sent unchanged. Other profile fields and roles stay unchanged. Fluxer checks ManageNicknames, role hierarchy and self-target rules. The frozen result follows HTTP, not a gateway event. Shared guild write deadlines and retries apply. Cancellation waits for request cleanup but cannot undo a dispatched change. An unknown outcome removes the target's cache entry, while a definite rejection preserves it

setNickname(
    member: MemberReference,
    nickname: string | null,
    options?: AuditedRequestOptions
): Effect<GuildMember, GuildOperationFailure>setNickname(
  member: MemberReference,
  nickname: string | null,
  options?: AuditedRequestOptions
): Effect<
  GuildMember,
  GuildOperationFailure
>

Parameters

nickname
string | null
options optional
AuditedRequestOptions
TypeScript
import { Effect } from "effect"
import type { Client, MemberReference } from "@neontechspace/fluxerly/effect"
export function nicknameExample(client: Client, target: MemberReference) {
    return Effect.gen(function* () {
        yield* client.members.setNickname(target, "Renamed")
        return yield* client.members.setNickname(target, null)
    })
}

setRoles#

Replace one member's entire assigned role list in a single PATCH request

Use 0–250 distinct positive decimal role IDs no greater than 9,223,372,036,854,775,807. An empty array clears assigned roles, and the implicit everyone role is rejected as input. IDs are copied by index when execution starts, without fetching or merging the old roles. Fluxer requires ManageRoles and checks hierarchy. This can overwrite concurrent role changes

setRoles(
    member: MemberReference,
    roleIds: readonly string[],
    options?: AuditedRequestOptions
): Effect<GuildMember, GuildOperationFailure>setRoles(
  member: MemberReference,
  roleIds: readonly string[],
  options?: AuditedRequestOptions
): Effect<
  GuildMember,
  GuildOperationFailure
>

Nonexistent or foreign role IDs may be silently omitted. The returned frozen member reports the actual role set, not a guarantee that every requested role was accepted. Shared guild write deadlines and confirmed HTTP 429 retries apply, without a gateway connection or event wait. Eligible results can update the member cache. Writes with unknown outcomes remove the old entry and need explicit fetch reconciliation. Cancellation waits for cleanup but cannot undo the replacement

Parameters

roleIds
readonly string[]
options optional
AuditedRequestOptions
TypeScript
import type { Client, MemberReference } from "@neontechspace/fluxerly/effect"
export function roleSetExample(client: Client, member: MemberReference, desiredRoles: readonly string[]) {
    return client.members.setRoles(member, desiredRoles)
}

timeout#

Temporarily restrict a community member for durationMs milliseconds

The duration must be an integer from 1 through 31,536,000,000 ms. Expiry is calculated when execution starts, so queue and network time consume part of the duration. If expiry is past when Fluxer processes it, the request can clear the timeout. ModerateMembers and Fluxer's hierarchy rules apply, and self and administrator targets are rejected. In a community whose mfaLevel is GuildMfaLevels.Elevated, the call fails with reason rejected, HTTP 400 and apiError.code twoFactorRequired, unless the bot owns the community or its application owner has two-factor authentication enabled. The returned frozen member contains communicationDisabledUntil after HTTP 200, without waiting for an event

timeout(
    target: MemberReference,
    durationMs: number,
    options?: TimeoutOptions
): Effect<GuildMember, GuildOperationFailure>timeout(
  target: MemberReference,
  durationMs: number,
  options?: TimeoutOptions
): Effect<
  GuildMember,
  GuildOperationFailure
>

Optional timeoutReason is provider audit metadata, separate from auditReason. It is not a member field or a guarantee that an audit entry is retained. Shared guild deadlines and failures apply, and only confirmed HTTP 429 rejection retries. Cancellation or closure waits for cleanup but cannot undo a dispatched timeout. Eligible results update an enabled member cache, and dispatched failures remove the member even on rejection

Parameters

durationMs
number
options optional
TimeoutOptions
TypeScript
import type { Client, MemberReference } from "@neontechspace/fluxerly/effect"
const moderationExample = (client: Client, target: MemberReference) =>
    client.members.timeout(target, 5 * 60_000)

timeoutState#

Report whether a member is timed out, from the member's communicationDisabledUntil and a moment in time

Returns "active" when the expiry is later than the moment, "none" when the member has no timeout or the expiry is at or before the moment, and "unknown" when the member omits the field, as a gateway member or cached member can. Use members.fetch, which always includes the field, to settle an unknown state. The moment is options.now, otherwise the wall time of the Clock that the client was created with. No request or cache read is made, and connection state is irrelevant, including after client shutdown. A timed-out member keeps its permission bits, but Fluxer blocks sending messages, editing and publishing the member's own messages, reacting, uploading, typing, changing the member's own nickname, writing in threads and joining voice, so check this beside permissions.calculate. A value that is not an object, an expiry that is neither null nor an ISO 8601 timestamp, or an invalid now is misuse and throws GuildOperationError for members.timeoutState with reason input in both APIs

timeoutState(
    member: Pick<GuildMember, "communicationDisabledUntil">,
    options?: TimeoutStateOptions
): MemberTimeoutStatetimeoutState(
  member: Pick<
    GuildMember,
    "communicationDisabledUntil"
  >,
  options?: TimeoutStateOptions
): MemberTimeoutState

Parameters

member
Pick<GuildMember, "communicationDisabledUntil">Pick<
  GuildMember,
  "communicationDisabledUntil"
>
options optional
TimeoutStateOptions

Returns the value synchronously, as in the default API, because the check is pure

TypeScript
import type { Client, GuildMember } from "@neontechspace/fluxerly/effect"
function timeoutExample(client: Client, member: GuildMember) {
    return client.members.timeoutState(member) === "active"
}

unban#

Remove a user's community ban, succeeding with no value after HTTP 204

BanMembers is required. A user who is not banned is an API error, not a successful no-op. The user is not rejoined and queued message deletion is not cancelled. The ban method's execution, failures, cleanup and cached-member invalidation apply

unban(
    target: MemberReference,
    options?: AuditedRequestOptions
): Effect<void, GuildOperationFailure>unban(
  target: MemberReference,
  options?: AuditedRequestOptions
): Effect<
  void,
  GuildOperationFailure
>

Parameters

options optional
AuditedRequestOptions

Re-Exports#

Declared in JavaScript & TypeScript and documented there. Import them from @neontechspace/fluxerly/effect as well

AuditLogActions#
Event categories for filtering a community's audit log, such as role changes, bans or invite creation
DiscoveryCategories#
Named category IDs for listing a community in Fluxer's public community directory
GuildContentWarningLevels#
Choose the community-wide warning policy through GuildEdit.contentWarningLevel
GuildDefaultMessageNotifications#
Set the initial notification preference for new community members through GuildEdit.defaultMessageNotifications
GuildExplicitContentFilters#
Choose whose uploaded media Fluxer filters for explicit content through GuildEdit.explicitContentFilter
GuildFeatureToggles#
Optional community behaviors that a bot with ManageGuild can replace through GuildEdit.featureToggles
GuildMemberJoinSourceTypes#
Fluxer's known sources for a community membership recorded by the indexed member-search service
GuildMemberProfileFlags#
Known Fluxer community-profile bit flags
GuildMfaLevels#
Values of Guild.mfaLevel, the community's two-factor requirement for moderation permissions
GuildSplashCardAlignments#
Position the card over the invite splash image through GuildEdit.splashCardAlignment
GuildSystemChannelFlags#
Suppress selected automatic messages in a community's system channel through GuildEdit.systemChannelFlags
GuildVerificationLevels#
Values for the verification policy required before members can participate in a community
MemberMentionPreferences#
Fluxer's per-community reply-mention preferences
AuditLogChange#
Before-and-after information for one field recorded by an audit entry
AuditLogEntry#
One recorded administrative action in a community, with any available actor, target, reason and changed settings
AuditLogIterationQueryBase#
Settings for reading filtered audit entries from newest to oldest, with explicit limits
AuditLogOptions#
Extra details for an audit record, such as the destination channel or number of affected items
AuditLogPage#
One filtered page of administrative records, with public user, token-free webhook and thread details used by that page
AuditLogPermissionsDiff#
Permission names added or removed by a recorded role change
AuditLogQueryBase#
Common settings for one filtered remote audit-log page request
AuditLogWebhook#
Frozen, token-free webhook metadata accompanying an audit-log page
BanInput#
Ban an account from a community permanently or for a provider-managed duration, optionally deleting recent messages
DeletedMessageMember#
The author's community membership as Fluxer attached it to a message deletion, with the account fields left out
DiscoveryApplication#
Current application or public listing returned by directory reads and writes
DiscoveryApplicationInput#
Describe a community for a public community-directory application
DiscoveryCategory#
A category returned by discovery.fetchCategories, with Fluxer's display name rather than an SDK-translated label
DiscoveryCategoryCount#
Frozen category match count for the current directory filters, ignoring the selected category
DiscoveryGuild#
Public community listing returned by discovery.search
DiscoverySearchPage#
One page of public community listings, with the offset, page limit and number of current matches
DiscoverySearchQuery#
Filter and choose one page of public community listings with discovery.search
DiscoveryStatus#
Current listing eligibility and application state returned by discovery.fetchStatus
Guild#
Identity and settings of a Fluxer guild, the community that owns channels, members and roles
GuildBan#
Recorded ban details returned by members.fetchBans, including available reason, moderator and expiry
GuildCount#
Member totals returned for one requested community by Fluxer's gateway
GuildCountsResult#
Results from one explicit request for several community counts, ordered to match the requested IDs
GuildEdit#
Change an existing community's settings through the bot client
GuildIterationQuery#
Limits and starting point for guilds.iterate, reading the bot's community memberships in ascending community-ID order
GuildListQuery#
One remote page of the authenticated bot's community memberships
GuildListSummary#
Details of one community this bot belongs to, freshly returned by the REST membership list
GuildMember#
A user's membership in one community, including assigned roles, community-profile settings and available moderation state
GuildVanityUrl#
The community's current custom invitation code and shareable URL, or null fields when no custom code is set
GuildVanityUrlUsage#
Custom invitation details with a use count returned by guilds.fetchVanityUrl
MemberChunk#
One batch yielded by members.iterateChunks, with frozen member observations and optional visible presences
MemberProfileEdit#
Change this bot's nickname and community-specific profile in one community
MemberQuery#
Select one REST page of community members, for example to inspect a bounded set or continue after a previous user ID
MemberReference#
Address one user's membership in one community for member reads and changes
MemberSearchHit#
A member matched by the search index, with indexed identity, roles and available membership-source details
MemberSearchIterationLimits#
Limit how much work members.iterateSearch may perform while reading matching indexed members
MemberSearchPage#
Matching indexed members and counts from one search request
MemberSearchQuery#
Search Fluxer's community member index by text, roles, join dates or how members joined
UserIterationQuery#
Limits and starting point for ascending member or reaction-user traversal
VoiceConnectionReference#
Identifies one member and, optionally, one of that member's active voice connections
VoiceDeafenInput#
The community deafen state to set for a member connected to voice
VoiceMuteInput#
The community mute state to set for a member connected to voice
AuditLogActionType#
One currently supported Fluxer audit-action value
AuditLogChangeValue#
A value recorded as a setting before or after an audit-log change
AuditLogFilter#
Choose an actor filter, action filter or both to read the audit log without changing it
AuditLogIterationQuery#
Read filtered audit entries from newest to oldest, bounded by the requested page and item limits
AuditLogQuery#
Read one page of community audit records for an actor, action category or both
DiscoveryApplicationEdit#
Change an existing directory application or listing with discovery.edit
GuildContentWarningLevel#
One Fluxer community-wide content-warning level
GuildDefaultMessageNotification#
One Fluxer default-notification level
GuildExplicitContentFilter#
One Fluxer explicit-media filtering level
GuildFeatureToggle#
One community feature that a bot can include in GuildEdit.featureToggles
GuildMemberJoinSourceType#
One known Fluxer community-member join source
GuildMfaLevel#
One Fluxer community two-factor requirement level
GuildSplashCardAlignment#
One Fluxer invite splash-card alignment
GuildSystemChannelFlag#
One known system-channel flag bit
GuildVerificationLevel#
One Fluxer member-verification level
MemberChunkQuery#
Choose the members to request through one community's gateway shard
MemberMentionPreference#
One of Fluxer's currently defined per-community reply-mention preferences
MemberTimeoutState#
Whether a member is timed out: "active" while the expiry is in the future, "none" when the member has no timeout or it has ended, and "unknown" when the member snapshot does not say