chore(release): v2.1.0 — update package snippets and docs#13
Merged
Conversation
… diagnostics Add RateLimitEvent diagnostic snapshot type Propagate onRateLimit handler through RateLimiter and HTTPClient to report waits and headers Add safe default base URLs in DiscordConfiguration and expose onRateLimit handler Implement CustomStringConvertible on DiscordError for clearer messages Remove unsafe nonisolated properties and fix actor ownership (Cache, DiscordClient) Minor ViewManager/Voice/Cache robustness fixes
…cordError tests Add TestFixtures helper for user/message/interaction payloads Update CacheTests/ViewManagerTests/DiscordConfigurationTests to use fixtures and add coverage for onRateLimit default
Use DISCORD_BOT_TOKEN in examples and add basic error handling around sends and logins Add executable example targets to Package.swift for quick local runs
…e for v2.1.0 Consolidate CI into a matrix for Ubuntu/macOS/Windows and wire platform-specific test scripts Add CONTRIBUTING.md and update CHANGELOG with 2.1.0 release notes; update docs to use DISCORD_BOT_TOKEN
Restore mutable eviction task to allow conditional initialization and avoid assignment errors; clear reference after cancelling to avoid retaining cancelled task.
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughConsolidates CI into a matrix job, modernizes examples to async/await, adds rate-limit observability and a RateLimitEvent type, improves error diagnostics with debugContext, extends message/component builders and validation, hardens gateway/connect logic (URLComponents, reconnection cap), and adds test fixtures and cross-platform test scripts. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant HTTPClient
participant RateLimiter
participant ExternalAPI
participant Config
Client->>HTTPClient: perform request (routeKey, request)
HTTPClient->>RateLimiter: waitTurn(routeKey)
RateLimiter-->>Config: onRateLimit?(RateLimitEvent) [before sleep]
RateLimiter->>RateLimiter: sleep if needed
RateLimiter-->>HTTPClient: allow proceed
HTTPClient->>ExternalAPI: send HTTP request
ExternalAPI-->>HTTPClient: response + rate-limit headers
HTTPClient->>RateLimiter: updateFromHeaders(routeKey, headers)
RateLimiter-->>Config: onRateLimit?(RateLimitEvent) [header-detected]
HTTPClient-->>Client: return response / throw
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
Sources/SwiftDisc/HighLevel/ViewManager.swift (1)
127-131:⚠️ Potential issue | 🟡 MinorDon't silently swallow invalid view regexes.
Line 131 still turns a malformed pattern into a normal miss, so a broken handler just never fires and the caller gets no signal. Please either validate
.regexpatterns during registration or emit a diagnostic here so bad routes fail loudly enough to debug.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Sources/SwiftDisc/HighLevel/ViewManager.swift` around lines 127 - 131, The code in ViewManager.swift currently swallows NSRegularExpression errors when matching a view pattern so malformed patterns silently never trigger their handler; update the logic to surface diagnostics when a regex fails (either validate the `.regex` pattern at registration time or log/emit an error here before treating it as a non-match). Concretely, catch the regex creation error around NSRegularExpression(pattern: pattern) and call the project's diagnostics/logging facility (or throw a registration/validation error) including the failing pattern and the caught error, or alternatively move validation into the view registration path to reject/raise on invalid `.regex` there; ensure references to pattern, NSRegularExpression, handler, matched, customId and the matching block are updated accordingly so malformed patterns fail loudly.
🧹 Nitpick comments (5)
Sources/SwiftDisc/Voice/VoiceClient.swift (1)
128-130: This diagnostics gate is effectively always-on for voice users.
VoiceClientis only created whenenableVoiceExperimentalis already true, so this now prints every handshake failure for all voice-enabled apps. If you want opt-in diagnostics, please hang this off a separate debug/logger hook instead of🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Sources/SwiftDisc/Voice/VoiceClient.swift` around lines 128 - 130, The current print in VoiceClient's handshake failure path uses configuration.enableVoiceExperimental (which is always true when VoiceClient exists) and thus logs for all voice users; replace the plain print("Voice handshake failed for guild \(guildId): \(error)") with an opt-in diagnostics/logging mechanism (e.g. call a debug/logger delegate or a separate configuration flag like voiceDiagnosticsEnabled) so only clients that subscribe get these messages; locate the print in VoiceClient where handshake failures are handled (references: VoiceClient, configuration.enableVoiceExperimental, guildId, error) and wire it to the app's logger or a new diagnostic hook instead of printing to stdout.Sources/SwiftDisc/HighLevel/ShardingGatewayManager.swift (1)
110-112: Avoid allocating a formatter on every log call.
log(_:_:)sits on connection/retry paths, so constructing a freshISO8601DateFormattereach time adds avoidable overhead. Since this method is actor-isolated, you can keep a cached formatter as an instance property without reintroducingnonisolated(unsafe).Possible refactor
+ private let logDateFormatter: ISO8601DateFormatter = { + let formatter = ISO8601DateFormatter() + return formatter + }() + private func log(_ level: LogLevel, _ message: `@autoclosure` () -> String) { - let ts = ISO8601DateFormatter().string(from: Date()) + let ts = logDateFormatter.string(from: Date()) print("[SwiftDisc][\(level.rawValue)] \(ts) - \(message())") }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Sources/SwiftDisc/HighLevel/ShardingGatewayManager.swift` around lines 110 - 112, The log(_:_:) method allocates a new ISO8601DateFormatter on every call; instead add a single cached ISO8601DateFormatter instance property on ShardingGatewayManager (e.g., private let iso8601Formatter = ISO8601DateFormatter()) and use that in log(_:_:) to format timestamps; since the method is actor-isolated you can store the formatter as an instance property without nonisolated/unsafe annotations — update references in log(_:_:) to call iso8601Formatter.string(from:) rather than constructing a new formatter.scripts/run-tests.sh (1)
9-10: Run the Docker fallback as the host user.The current fallback writes build artifacts as root inside the mounted repo, which is a recurring local-dev footgun after
swift testcreates.build. Pass the caller UID/GID through the container so reruns and cleanup stay writable.Proposed tweak
- docker run --rm -v "$(pwd):/workspace" -w /workspace swift:5.9 /bin/bash -lc "swift test" + docker run --rm \ + --user "$(id -u):$(id -g)" \ + -v "$(pwd):/workspace" \ + -w /workspace \ + swift:5.9 \ + /bin/bash -lc "swift test"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/run-tests.sh` around lines 9 - 10, The fallback Docker invocation runs as root and creates root-owned build artifacts; modify the docker run command (the line invoking docker run with swift:5.9) to run as the host caller by adding the --user flag with the host UID and GID (e.g. --user "$(id -u):$(id -g)") and preserve the same volume and working-dir flags so that swift test runs inside the container as the calling user and created files remain writable by the host user.Package.swift (1)
20-69: Consider deduplicating repeated executable target boilerplate.This block is repetitive and will be harder to maintain as examples grow. A tiny helper keeps behavior identical and reduces copy/paste drift.
Refactor sketch
+func exampleTarget(_ name: String, _ source: String) -> Target { + .executableTarget( + name: name, + dependencies: ["SwiftDisc"], + path: "Examples", + sources: [source], + swiftSettings: [.swiftLanguageMode(.v6)] + ) +} + let package = Package( @@ targets: [ .target( name: "SwiftDisc", swiftSettings: [.swiftLanguageMode(.v6)] ), - .executableTarget(name: "PingBotExample", dependencies: ["SwiftDisc"], path: "Examples", sources: ["PingBot.swift"], swiftSettings: [.swiftLanguageMode(.v6)]), - .executableTarget(name: "SlashBotExample", dependencies: ["SwiftDisc"], path: "Examples", sources: ["SlashBot.swift"], swiftSettings: [.swiftLanguageMode(.v6)]), - .executableTarget(name: "CommandsBotExample", dependencies: ["SwiftDisc"], path: "Examples", sources: ["CommandsBot.swift"], swiftSettings: [.swiftLanguageMode(.v6)]), - .executableTarget(name: "AutocompleteBotExample", dependencies: ["SwiftDisc"], path: "Examples", sources: ["AutocompleteBot.swift"], swiftSettings: [.swiftLanguageMode(.v6)]), - .executableTarget(name: "FileUploadBotExample", dependencies: ["SwiftDisc"], path: "Examples", sources: ["FileUploadBot.swift"], swiftSettings: [.swiftLanguageMode(.v6)]), - .executableTarget(name: "ComponentsExample", dependencies: ["SwiftDisc"], path: "Examples", sources: ["ComponentsExample.swift"], swiftSettings: [.swiftLanguageMode(.v6)]), - .executableTarget(name: "ViewExample", dependencies: ["SwiftDisc"], path: "Examples", sources: ["ViewExample.swift"], swiftSettings: [.swiftLanguageMode(.v6)]), + exampleTarget("PingBotExample", "PingBot.swift"), + exampleTarget("SlashBotExample", "SlashBot.swift"), + exampleTarget("CommandsBotExample", "CommandsBot.swift"), + exampleTarget("AutocompleteBotExample", "AutocompleteBot.swift"), + exampleTarget("FileUploadBotExample", "FileUploadBot.swift"), + exampleTarget("ComponentsExample", "ComponentsExample.swift"), + exampleTarget("ViewExample", "ViewExample.swift"), .testTarget( name: "SwiftDiscTests", dependencies: ["SwiftDisc"], swiftSettings: [.swiftLanguageMode(.v6)] )🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Package.swift` around lines 20 - 69, The Package.swift targets block repeats many .executableTarget(...) entries; create a small helper function (e.g., makeExampleTarget(name: String, source: String) -> Target) and use it to construct each example target so the boilerplate (dependencies: ["SwiftDisc"], path: "Examples", swiftSettings: [.swiftLanguageMode(.v6)]) is centralized; update each current .executableTarget calls (the PingBotExample, SlashBotExample, CommandsBotExample, AutocompleteBotExample, FileUploadBotExample, ComponentsExample, ViewExample entries) to invoke the helper instead so adding/removing examples only changes a single spot.Tests/SwiftDiscTests/TestFixtures.swift (1)
31-64: Parameterize interaction/component type values instead of hardcoding.Line 31 through Line 64 currently locks the fixture to one interaction shape (
type: 3,component_type: 2). Exposing these as defaults makes the helper reusable for more test cases without duplicating this constructor.Refactor sketch
- static func makeComponentInteraction(customId: String, guildId: String = "guild", channelId: String = "chan", id: String = "1", applicationId: String = "app", token: String = "tok") -> Interaction { + static func makeComponentInteraction( + customId: String, + guildId: String = "guild", + channelId: String = "chan", + id: String = "1", + applicationId: String = "app", + token: String = "tok", + interactionType: Int = 3, + componentType: Int = 2 + ) -> Interaction { @@ - component_type: 2, + component_type: componentType, @@ - type: 3, + type: interactionType,🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Tests/SwiftDiscTests/TestFixtures.swift` around lines 31 - 64, The fixture makeComponentInteraction currently hardcodes interaction type and component_type (type: 3 and component_type: 2); modify the function signature to accept optional parameters like interactionType (default 3) and componentType (default 2), then use those parameters when constructing Interaction (set its type to interactionType) and Interaction.ApplicationCommandData (set component_type to componentType) so callers can override the values for different test cases (update any tests that rely on the old signature to pass explicit values if needed).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Examples/CogExample.swift`:
- Line 9: The assignment to the actor-isolated property client.onMessage must be
performed with await; update the code that sets client.onMessage to perform the
assignment from an async context (for example wrap the assignment in an async
Task or call site that uses await) so the actor isolation rules are respected
when mutating the onMessage property in Examples/CogExample.swift.
In `@Examples/README.md`:
- Around line 20-30: Update the SwiftPM run commands in the README section:
replace both instances of "swift run PingBotExample" with the executable target
for the Autocomplete example (the executable for Examples/AutocompleteBot.swift,
e.g. "swift run AutocompleteBotExample") so the shell and PowerShell snippets
launch the Autocomplete sample instead of the Ping example.
In `@InstallGuide.txt`:
- Around line 105-115: Replace all usages of the Docker image tag "swift:5.9"
with "swift:6.2" (i.e., update the literal string "swift:5.9" found in
InstallGuide.txt and in the scripts run-tests.sh and run-tests.ps1), and also
update the user-facing messages in run-tests.sh and run-tests.ps1 that reference
the swift image version so they mention swift:6.2 instead of 5.9.
In `@README.md`:
- Around line 155-167: The README Command Framework snippet calls actor-isolated
APIs without awaiting them; update the snippet to use await where required: call
await router.register("ping") { ... } instead of router.register(...), and await
the isolated setter when assigning the handler (await client.onMessage = {
message in ... }); ensure other calls like await
router.handleIfCommand(message:client:) and try await ctx.message.reply(...)
remain awaited as shown.
In `@scripts/run-tests.ps1`:
- Around line 14-15: The Docker fallback in scripts/run-tests.ps1 uses the old
image tag "swift:5.9" which mismatches Package.swift; update the docker run
invocation to use "swift:6.2" and also update the accompanying Write-Output
message ("Native Swift not found; running tests in Docker (swift:6.2)") so the
log and the docker image tag (in the docker run command) both reflect Swift 6.2.
In `@Sources/SwiftDisc/DiscordClient.swift`:
- Around line 17-18: You exposed a single AsyncStream instance
(eventStream/eventContinuation) which causes multiple iterators (e.g.,
ViewManager.start(client:)) to compete for events; instead, change the API to
provide per-subscriber streams or a multicast broadcaster: replace the single
eventContinuation with a thread-safe collection of continuations (e.g.,
eventContinuations), add a public func events() -> AsyncStream<DiscordEvent>
that creates and returns a new AsyncStream per caller (registering its
continuation in eventContinuations and removing it on termination), and change
the internal event dispatch path to iterate that collection and yield the
incoming DiscordEvent to every continuation; alternatively implement a proper
multicast via swift-async-algorithms, but do not return the single private
eventStream directly to callers.
In `@Sources/SwiftDisc/Internal/Cache.swift`:
- Around line 36-38: The bootstrap uses an untracked Task to call
startEvictionTaskIfNeeded which races with stopEviction; instead either invoke
startEvictionTaskIfNeeded synchronously once initialization completes or store
the Task handle in evictionBootstrapTask (or reuse evictionTask) so stopEviction
can cancel it; update the spots that create Task { [weak self] in await
self?.startEvictionTaskIfNeeded() } (and the similar code at 145-150) to either
call await startEvictionTaskIfNeeded() directly or assign the created Task to a
cancellable property and ensure stopEviction cancels that property and
awaits/clears it along with evictionTask.
In `@Sources/SwiftDisc/REST/RateLimiter.swift`:
- Line 79: The onRateLimit? callback is being invoked unconditionally with
RateLimitEvent(routeKey: routeKey, isGlobal: false, remaining: state.remaining,
limit: state.limit, resetAt: state.resetAt) even when no bucket fields changed;
update the emission logic in RateLimiter (where the per-route event is
constructed) to only call onRateLimit? when header parsing actually modified the
bucket state (e.g., remaining, limit, or resetAt changed) or when a boolean flag
like didUpdateBucket is true—compare the new values against the previous
bucket/state or set a local updated flag during header processing and use that
to gate the onRateLimit? call so you avoid false-positive telemetry.
---
Outside diff comments:
In `@Sources/SwiftDisc/HighLevel/ViewManager.swift`:
- Around line 127-131: The code in ViewManager.swift currently swallows
NSRegularExpression errors when matching a view pattern so malformed patterns
silently never trigger their handler; update the logic to surface diagnostics
when a regex fails (either validate the `.regex` pattern at registration time or
log/emit an error here before treating it as a non-match). Concretely, catch the
regex creation error around NSRegularExpression(pattern: pattern) and call the
project's diagnostics/logging facility (or throw a registration/validation
error) including the failing pattern and the caught error, or alternatively move
validation into the view registration path to reject/raise on invalid `.regex`
there; ensure references to pattern, NSRegularExpression, handler, matched,
customId and the matching block are updated accordingly so malformed patterns
fail loudly.
---
Nitpick comments:
In `@Package.swift`:
- Around line 20-69: The Package.swift targets block repeats many
.executableTarget(...) entries; create a small helper function (e.g.,
makeExampleTarget(name: String, source: String) -> Target) and use it to
construct each example target so the boilerplate (dependencies: ["SwiftDisc"],
path: "Examples", swiftSettings: [.swiftLanguageMode(.v6)]) is centralized;
update each current .executableTarget calls (the PingBotExample,
SlashBotExample, CommandsBotExample, AutocompleteBotExample,
FileUploadBotExample, ComponentsExample, ViewExample entries) to invoke the
helper instead so adding/removing examples only changes a single spot.
In `@scripts/run-tests.sh`:
- Around line 9-10: The fallback Docker invocation runs as root and creates
root-owned build artifacts; modify the docker run command (the line invoking
docker run with swift:5.9) to run as the host caller by adding the --user flag
with the host UID and GID (e.g. --user "$(id -u):$(id -g)") and preserve the
same volume and working-dir flags so that swift test runs inside the container
as the calling user and created files remain writable by the host user.
In `@Sources/SwiftDisc/HighLevel/ShardingGatewayManager.swift`:
- Around line 110-112: The log(_:_:) method allocates a new ISO8601DateFormatter
on every call; instead add a single cached ISO8601DateFormatter instance
property on ShardingGatewayManager (e.g., private let iso8601Formatter =
ISO8601DateFormatter()) and use that in log(_:_:) to format timestamps; since
the method is actor-isolated you can store the formatter as an instance property
without nonisolated/unsafe annotations — update references in log(_:_:) to call
iso8601Formatter.string(from:) rather than constructing a new formatter.
In `@Sources/SwiftDisc/Voice/VoiceClient.swift`:
- Around line 128-130: The current print in VoiceClient's handshake failure path
uses configuration.enableVoiceExperimental (which is always true when
VoiceClient exists) and thus logs for all voice users; replace the plain
print("Voice handshake failed for guild \(guildId): \(error)") with an opt-in
diagnostics/logging mechanism (e.g. call a debug/logger delegate or a separate
configuration flag like voiceDiagnosticsEnabled) so only clients that subscribe
get these messages; locate the print in VoiceClient where handshake failures are
handled (references: VoiceClient, configuration.enableVoiceExperimental,
guildId, error) and wire it to the app's logger or a new diagnostic hook instead
of printing to stdout.
In `@Tests/SwiftDiscTests/TestFixtures.swift`:
- Around line 31-64: The fixture makeComponentInteraction currently hardcodes
interaction type and component_type (type: 3 and component_type: 2); modify the
function signature to accept optional parameters like interactionType (default
3) and componentType (default 2), then use those parameters when constructing
Interaction (set its type to interactionType) and
Interaction.ApplicationCommandData (set component_type to componentType) so
callers can override the values for different test cases (update any tests that
rely on the old signature to pass explicit values if needed).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: daf0a601-811f-4cc2-af50-1b11b87401c7
📒 Files selected for processing (34)
.github/workflows/ci.ymlCHANGELOG.mdCONTRIBUTING.mdExamples/AutocompleteBot.swiftExamples/CogExample.swiftExamples/CommandFrameworkBot.swiftExamples/CommandsBot.swiftExamples/ComponentsExample.swiftExamples/FileUploadBot.swiftExamples/PingBot.swiftExamples/README.mdExamples/SlashBot.swiftExamples/ViewExample.swiftInstallGuide.txtPackage.swiftREADME.mdSources/SwiftDisc/DiscordClient.swiftSources/SwiftDisc/HighLevel/ShardingGatewayManager.swiftSources/SwiftDisc/HighLevel/ViewManager.swiftSources/SwiftDisc/Internal/Cache.swiftSources/SwiftDisc/Internal/DiscordConfiguration.swiftSources/SwiftDisc/Internal/DiscordError.swiftSources/SwiftDisc/REST/HTTPClient.swiftSources/SwiftDisc/REST/RateLimitEvent.swiftSources/SwiftDisc/REST/RateLimiter.swiftSources/SwiftDisc/Voice/VoiceClient.swiftSwiftDiscDocs.txtTests/SwiftDiscTests/CacheTests.swiftTests/SwiftDiscTests/DiscordConfigurationTests.swiftTests/SwiftDiscTests/DiscordErrorTests.swiftTests/SwiftDiscTests/TestFixtures.swiftTests/SwiftDiscTests/ViewManagerTests.swiftscripts/run-tests.ps1scripts/run-tests.sh
There was a problem hiding this comment.
🧹 Nitpick comments (1)
Examples/PingBot.swift (1)
8-8: Fail fast ifDISCORD_BOT_TOKENis missing.Using a placeholder token can produce noisy auth failures. Prefer explicit env validation and early exit.
Suggested change
- let token = ProcessInfo.processInfo.environment["DISCORD_BOT_TOKEN"] ?? "YOUR_BOT_TOKEN" + guard let token = ProcessInfo.processInfo.environment["DISCORD_BOT_TOKEN"], + !token.isEmpty else { + print("❌ Missing DISCORD_BOT_TOKEN") + return + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Examples/PingBot.swift` at line 8, The code currently assigns a placeholder when DISCORD_BOT_TOKEN is missing; instead, fail fast by validating the env var: replace the loose assignment of token (the let token = ProcessInfo.processInfo.environment["DISCORD_BOT_TOKEN"] ?? "YOUR_BOT_TOKEN") with a guard/if that checks ProcessInfo.processInfo.environment["DISCORD_BOT_TOKEN"] and, if nil or empty, logs an explicit error and exits (e.g., print error and exit(1)) before proceeding to use the token.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@Examples/PingBot.swift`:
- Line 8: The code currently assigns a placeholder when DISCORD_BOT_TOKEN is
missing; instead, fail fast by validating the env var: replace the loose
assignment of token (the let token =
ProcessInfo.processInfo.environment["DISCORD_BOT_TOKEN"] ?? "YOUR_BOT_TOKEN")
with a guard/if that checks
ProcessInfo.processInfo.environment["DISCORD_BOT_TOKEN"] and, if nil or empty,
logs an explicit error and exits (e.g., print error and exit(1)) before
proceeding to use the token.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 59eb5c1f-4fa2-4c49-896c-e04def259153
📒 Files selected for processing (13)
Examples/AutocompleteBot.swiftExamples/CogExample.swiftExamples/CommandFrameworkBot.swiftExamples/CommandsBot.swiftExamples/ComponentsExample.swiftExamples/FileUploadBot.swiftExamples/LinkedRolesBot.swiftExamples/PingBot.swiftExamples/SlashBot.swiftExamples/ThreadsAndScheduledEventsBot.swiftExamples/ViewExample.swiftExamples/VoiceStdin.swiftTests/SwiftDiscTests/TestFixtures.swift
✅ Files skipped from review due to trivial changes (3)
- Examples/ThreadsAndScheduledEventsBot.swift
- Examples/LinkedRolesBot.swift
- Examples/VoiceStdin.swift
🚧 Files skipped from review as they are similar to previous changes (9)
- Examples/AutocompleteBot.swift
- Examples/CommandsBot.swift
- Examples/FileUploadBot.swift
- Examples/CommandFrameworkBot.swift
- Examples/SlashBot.swift
- Examples/CogExample.swift
- Examples/ComponentsExample.swift
- Tests/SwiftDiscTests/TestFixtures.swift
- Examples/ViewExample.swift
There was a problem hiding this comment.
🧹 Nitpick comments (1)
Tests/SwiftDiscTests/TestFixtures.swift (1)
34-73: Consider makingguildId/channelIdoptional for broader test reuse.This fixture is good for guild interactions, but optional params would also cover DM interaction paths without another helper.
♻️ Suggested refactor
- static func makeComponentInteraction(customId: String, guildId: String = "guild", channelId: String = "chan", id: String = "1", applicationId: String = "app", token: String = "tok") -> Interaction { + static func makeComponentInteraction(customId: String, guildId: String? = "guild", channelId: String? = "chan", id: String = "1", applicationId: String = "app", token: String = "tok") -> Interaction { let interactionId = InteractionID(id) let appId = ApplicationID(applicationId) - let gid = GuildID(guildId) - let cid = ChannelID(channelId) + let gid = guildId.map(GuildID.init) + let cid = channelId.map(ChannelID.init)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Tests/SwiftDiscTests/TestFixtures.swift` around lines 34 - 73, The fixture makeComponentInteraction currently forces guildId and channelId for guild interactions only; change its signature to accept optional guildId: String? = nil and channelId: String? = nil, then only construct GuildID/GuildID(...) and ChannelID(...) when those optionals are non-nil and pass nil to Interaction.guild_id and Interaction.channel_id when absent; update references to InteractionID, ApplicationID, data creation remains same, and update any callers/tests to pass explicit values where a guild/channel are required.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@Tests/SwiftDiscTests/TestFixtures.swift`:
- Around line 34-73: The fixture makeComponentInteraction currently forces
guildId and channelId for guild interactions only; change its signature to
accept optional guildId: String? = nil and channelId: String? = nil, then only
construct GuildID/GuildID(...) and ChannelID(...) when those optionals are
non-nil and pass nil to Interaction.guild_id and Interaction.channel_id when
absent; update references to InteractionID, ApplicationID, data creation remains
same, and update any callers/tests to pass explicit values where a guild/channel
are required.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 8ad752c1-324f-486e-b5df-7805ee81d3e6
📒 Files selected for processing (1)
Tests/SwiftDiscTests/TestFixtures.swift
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
README.md (1)
55-56: Fail fast whenDISCORD_BOT_TOKENis missing.Using
?? ""silently creates an invalid client config. A guard with a clear message gives better first-run DX.Proposed fix
- let token = ProcessInfo.processInfo.environment["DISCORD_BOT_TOKEN"] ?? "" + guard let token = ProcessInfo.processInfo.environment["DISCORD_BOT_TOKEN"], !token.isEmpty else { + print("Missing DISCORD_BOT_TOKEN") + return + }Also applies to: 91-92
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@README.md` around lines 55 - 56, Replace the silent default empty token with a fail-fast check: after reading ProcessInfo.processInfo.environment["DISCORD_BOT_TOKEN"] into token, guard that token is non-empty (or throw/exit) and log/print a clear error before creating DiscordClient(token:). Update both occurrences (the token assignment used with DiscordClient) so the app aborts with a descriptive message when DISCORD_BOT_TOKEN is missing instead of constructing an invalid DiscordClient.DXResearch.md (1)
28-33: Improve list readability by reducing repetitive “Add …” starts.Lines 28–33 are clear, but the repeated sentence opening makes the section feel mechanical. Consider varying verbs to improve scanability.
Suggested wording tweak
-1. Add a dedicated quickstart doc with copy-paste minimal bots for message, slash command, and component flows. -2. Add an intents-and-permissions guide with practical presets by bot type. -3. Add a troubleshooting page with CI/platform-specific known issues. -4. Add a migration note from 2.0 to 2.1. -5. Add a logging guide with suggested structured logging defaults. -6. Add a small starter-template repository linked from README. +1. Publish a dedicated quickstart doc with copy-paste minimal bots for message, slash command, and component flows. +2. Provide an intents-and-permissions guide with practical presets by bot type. +3. Create a troubleshooting page with CI/platform-specific known issues. +4. Include a migration note from 2.0 to 2.1. +5. Document suggested structured logging defaults. +6. Link a small starter-template repository from the README.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@DXResearch.md` around lines 28 - 33, The numbered list (items 1–6) in DXResearch.md uses the repetitive opener “Add …” which reduces scanability; update the six bullets to use varied, parallel verbs while preserving meaning—for example replace items with verbs like “Create a dedicated quickstart…”, “Include an intents-and-permissions guide…”, “Provide a troubleshooting page…”, “Document a migration note…”, “Publish a logging guide…”, and “Link a starter-template repo…”, ensuring consistent punctuation and concise phrasing across the list.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@README.md`:
- Line 103: The call to client.useSlashCommands(slash) is synchronous but is
invoked with an unnecessary await; remove the await keyword from the invocation
of useSlashCommands (i.e., change `await client.useSlashCommands(slash)` to
`client.useSlashCommands(slash)`) so the code calls the synchronous
DiscordClient.swift method correctly and no longer expects a suspended result.
- Line 105: The snippet using try? await client.loginAndConnect(intents:
[.guilds]) silently swallows login/connect errors; replace it with an explicit
do/catch around client.loginAndConnect to surface and handle errors (log the
error via your logger or print the error and exit/propagate), mirroring the
message-bot quick-start pattern; locate the call to client.loginAndConnect in
the README example and wrap it in a do { try await client.loginAndConnect(...) }
catch { /* log/print error and exit or rethrow */ } so failures are not
suppressed.
---
Nitpick comments:
In `@DXResearch.md`:
- Around line 28-33: The numbered list (items 1–6) in DXResearch.md uses the
repetitive opener “Add …” which reduces scanability; update the six bullets to
use varied, parallel verbs while preserving meaning—for example replace items
with verbs like “Create a dedicated quickstart…”, “Include an
intents-and-permissions guide…”, “Provide a troubleshooting page…”, “Document a
migration note…”, “Publish a logging guide…”, and “Link a starter-template
repo…”, ensuring consistent punctuation and concise phrasing across the list.
In `@README.md`:
- Around line 55-56: Replace the silent default empty token with a fail-fast
check: after reading ProcessInfo.processInfo.environment["DISCORD_BOT_TOKEN"]
into token, guard that token is non-empty (or throw/exit) and log/print a clear
error before creating DiscordClient(token:). Update both occurrences (the token
assignment used with DiscordClient) so the app aborts with a descriptive message
when DISCORD_BOT_TOKEN is missing instead of constructing an invalid
DiscordClient.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: bc51e057-83cc-4fff-aa6f-67f1e32c8a11
📒 Files selected for processing (4)
CHANGELOG.mdDXResearch.mdInstallGuide.txtREADME.md
💤 Files with no reviewable changes (1)
- InstallGuide.txt
✅ Files skipped from review due to trivial changes (1)
- CHANGELOG.md
Owner
Author
|
Preparing review... |
1 similar comment
Owner
Author
|
Preparing review... |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
DXResearch.md (1)
31-33: Reduce repetitive phrasing in the backlog list.Lines 31–33 repeat “Add …” consecutively; small wording variation will read cleaner.
✍️ Suggested wording tweak
-4. Add a migration note from 2.0 to 2.1. -5. Add a logging guide with suggested structured logging defaults. -6. Add a small starter-template repository linked from README. +4. Publish a migration note from 2.0 to 2.1. +5. Document logging guidance with suggested structured logging defaults. +6. Provide a small starter-template repository linked from README.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@DXResearch.md` around lines 31 - 33, The three backlog items currently all start with "Add ...", which is repetitive; update the three lines ("Add a migration note from 2.0 to 2.1.", "Add a logging guide with suggested structured logging defaults.", "Add a small starter-template repository linked from README.") to use varied verbs and phrasing (e.g., "Document a migration note from 2.0 to 2.1.", "Include a logging guide with suggested structured logging defaults.", "Create a small starter-template repository and link it from the README.") so the list reads cleaner and avoids repeated "Add".
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@DXResearch.md`:
- Around line 31-33: The three backlog items currently all start with "Add ...",
which is repetitive; update the three lines ("Add a migration note from 2.0 to
2.1.", "Add a logging guide with suggested structured logging defaults.", "Add a
small starter-template repository linked from README.") to use varied verbs and
phrasing (e.g., "Document a migration note from 2.0 to 2.1.", "Include a logging
guide with suggested structured logging defaults.", "Create a small
starter-template repository and link it from the README.") so the list reads
cleaner and avoids repeated "Add".
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 1fadab35-9c1a-49d5-8210-affe6adfa04b
📒 Files selected for processing (4)
CHANGELOG.mdDXResearch.mdInstallGuide.txtREADME.md
💤 Files with no reviewable changes (1)
- InstallGuide.txt
✅ Files skipped from review due to trivial changes (2)
- CHANGELOG.md
- README.md
Owner
Author
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
Add support for Discord's new File Upload modal component introduced in 2026, allowing users to upload files through modal submissions. Changes: - Add MessageComponent.fileUpload(FileUpload) enum case (type 25) - Add decoder case for type 25 in MessageComponent.init(from:) - Add encoder case for fileUpload in MessageComponent.encode(to:) - Add FileUpload struct with required fields: - type: Int = 25 - custom_id: String - label: String - min_length: Int? (minimum number of files) - max_length: Int? (maximum number of files) - required: Bool? - placeholder: String? - Add fileUpload case to ViewManager.disableComponents() to handle component disabling when views expire This component must be used inside a Label container (type 21) per Discord's modal component specification. The implementation follows the same pattern as other modal components (RadioGroup, CheckboxGroup, Checkbox) added in v1.3.0. Reference: Discord API changelog - Introducing the File Upload component in Modals
Add support for Discord's Search Guild Messages REST endpoint introduced in 2026,
enabling message search within guilds for moderation and content discovery.
Changes:
- Add searchGuildMessages() method to DiscordClient with comprehensive query parameters:
- guildId: GuildID - target guild to search
- query: String? - content search string (URL-encoded)
- authorId: UserID? - filter by message author
- minId: MessageID? - search messages after this ID
- maxId: MessageID? - search messages before this ID
- has: String? - filter by message attributes (link, embed, file, etc.)
- limit: Int? - maximum number of results to return
- offset: Int? - pagination offset
- Endpoint: GET /guilds/{guild.id}/messages/search
- Query string construction with proper URL encoding for content parameter
- Returns array of Message objects matching search criteria
This endpoint requires READ_MESSAGE_HISTORY and MESSAGE_CONTENT intents per
Discord API specification. The implementation follows the same pattern as other
message-related endpoints (getMessage, listChannelMessages) and includes proper
query parameter encoding to handle special characters in search queries.
Reference: Discord API changelog - Search Guild Messages
… modes Add support for Discord's modern voice encryption modes introduced in 2026, providing type-safe enum values while maintaining backward compatibility. Changes: - Add VoiceEncryptionMode enum with cases for all Discord-supported modes: - xsalsa20_poly1305 (currently implemented via Secretbox) - aead_aes256_gcm_rtpsize (reserved for future implementation) - aead_xchacha20_poly1305_rtpsize (reserved for future implementation) - aead_aes256_gcm (reserved for future implementation) - Update selectProtocol() method signature to use VoiceEncryptionMode instead of String - Maintain default value as .xsalsa20_poly1305 for backward compatibility - Convert enum to rawValue when sending to Discord API - Add comprehensive documentation noting implementation status Note: Only xsalsa20_poly1305 is currently functional in SwiftDisc via the Secretbox implementation. The newer AEAD modes (aead_aes256_gcm_rtpsize, aead_xchacha20_poly1305_rtpsize, aead_aes256_gcm) require additional cryptographic implementation and are reserved for future support. This change provides the API surface for these modes without breaking existing functionality. Reference: Discord API changelog - Voice Encryption Modes
Upgrade Discord voice gateway connection from version 4 to version 8 to support Discord's new voice gateway features including buffered resume support. Changes: - Update VoiceGateway.connect() to use v=8 instead of v=4 in query string - Voice gateway version 8 provides buffered resume capability for re-sending lost messages - Discord has deprecated versions < 4 and removed the default version option - Version 8 is now the recommended standard for voice gateway connections This change is necessary as Discord is actively deprecating older voice gateway versions. Voice gateway version 8 introduces buffered resume support which improves reliability by allowing the gateway to re-send lost messages during reconnection events. The upgrade maintains backward compatibility with existing voice functionality while enabling future improvements. Note: Voice implementation remains experimental in SwiftDisc. This upgrade provides the foundation for future voice enhancements including E2EE support. Reference: Discord API changelog - Voice Gateway Version 8 and Deprecation of Versions < 4
Add fluent builder APIs for Discord's new modal components (Label, RadioGroup, CheckboxGroup, Checkbox, FileUpload) to improve developer ergonomics and provide type-safe component construction. Changes: - Add LabelBuilder for modal container components: - label(String) - set the label text - description(String?) - optional description - components([MessageComponent]?) - child components - Add RadioGroupBuilder for single-selection modals: - customId(String) - component identifier - option(label:value:description:isDefault:) - add radio option - required(Bool) - mark as required - Add CheckboxGroupBuilder for multi-selection modals: - customId(String) - component identifier - option(label:value:description:isDefault:) - add checkbox option - minValues(Int) - minimum selections - maxValues(Int) - maximum selections - Add CheckboxBuilder for boolean toggle modals: - customId(String) - component identifier - required(Bool) - mark as required - default(Bool) - set default checked state - Add FileUploadBuilder for file upload modals: - customId(String) - component identifier - label(String) - upload label - minLength(Int) - minimum file count - maxLength(Int) - maximum file count - required(Bool) - mark as required - placeholder(String) - placeholder text All builders follow the same pattern as existing SwiftDisc builders (ButtonBuilder, SelectMenuBuilder, TextInputBuilder) with fluent method chaining and immutable state, ensuring type safety and compile-time validation. These builders provide a more ergonomic API than manually constructing component structs, reducing boilerplate and improving code readability for modal-heavy interactions.
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
Sources/SwiftDisc/DiscordClient.swift (1)
903-907: Consider avoiding force-unwrap after nil check.The pattern
limit != nil ? "?limit=\(limit!)" : ""is safe but not idiomatic Swift. A cleaner alternative:- let q = limit != nil ? "?limit=\(limit!)" : "" + let q = limit.map { "?limit=\($0)" } ?? ""Same applies to line 940.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Sources/SwiftDisc/DiscordClient.swift` around lines 903 - 907, The code in getReactions (and the similar occurrence around line 940) force-unwraps limit with "\(limit!)" even though it's been checked; change to use optional binding or map to avoid force-unwrapping—e.g., compute the query string with if let limit = limit { "?limit=\(limit)" } else { "" } or use limit.map { "?limit=\($0)" } ?? ""—so update the logic in getReactions and the other function to build q without force-unwraps.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Sources/SwiftDisc/DiscordClient.swift`:
- Around line 838-850: searchGuildMessages currently tries to decode the search
endpoint directly to [Message], but Discord returns a wrapper object whose
messages field is [[Message]]; create a response wrapper (e.g.,
GuildMessagesSearchResponse with messages: [[Message]] and optional
total_results/other fields) and change the GET call to decode to that wrapper
(use the existing http.get decoding path for GuildMessagesSearchResponse), then
flatten the nested array with messages.flatMap { $0 } and return the flattened
[Message] from searchGuildMessages; keep the public signature returning
[Message] and only adjust the decoding/return inside the searchGuildMessages
function.
In `@Sources/SwiftDisc/HighLevel/ComponentsBuilder.swift`:
- Around line 89-123: RadioGroupBuilder.build and CheckboxGroupBuilder.build
must validate builder state before constructing MessageComponent: ensure
customId is non-empty and options is not empty; for CheckboxGroupBuilder also
validate minValues/maxValues (if both set, require 0 <= minValues <= maxValues
and both <= options.count; if only one set ensure it's within
0...options.count). Implement these checks inside RadioGroupBuilder.build and
CheckboxGroupBuilder.build (using precondition, throw, or returning
Result/optional per project convention) and return/raise clear errors mentioning
the field (customId, options, minValues, maxValues) so invalid configs fail fast
instead of reaching the API.
- Around line 79-85: LabelBuilder currently stores an array and exposes
components(_ comps: [MessageComponent]) allowing multiple children, violating
the Label single-child contract; change the builder to store a single
MessageComponent (e.g., replace private var components: [MessageComponent]? with
a single optional component property), change the setter signature
components(_:) to accept one MessageComponent (or add a new components(_ comp:
MessageComponent) overload) and update build() to pass that single component
into .label(...); also add a nil-check/validation so build() fails or logs
clearly if no child was provided.
In `@Sources/SwiftDisc/Voice/VoiceGateway.swift`:
- Around line 7-12: Validate the chosen VoiceEncryptionMode against the
server-negotiated list and the library's supported implementations before
sending the selectProtocol payload: in the code path that builds/sends
selectProtocol (referencing the selectProtocol sender and the Ready.modes value
captured from the Ready event), check that the selected mode.rawValue exists in
Ready.modes and is one of the implemented modes (currently only
VoiceEncryptionMode.xsalsa20_poly1305); if it is not present or not supported,
do not send the payload and instead fail fast (return an error/throw or log and
close the voice setup) or choose a safe fallback mode, ensuring the message to
the server never contains an unsupported mode which would trigger close code
4016.
---
Nitpick comments:
In `@Sources/SwiftDisc/DiscordClient.swift`:
- Around line 903-907: The code in getReactions (and the similar occurrence
around line 940) force-unwraps limit with "\(limit!)" even though it's been
checked; change to use optional binding or map to avoid force-unwrapping—e.g.,
compute the query string with if let limit = limit { "?limit=\(limit)" } else {
"" } or use limit.map { "?limit=\($0)" } ?? ""—so update the logic in
getReactions and the other function to build q without force-unwraps.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: f9af3adf-b519-4c5f-9d56-3792cf0c9e53
📒 Files selected for processing (5)
Sources/SwiftDisc/DiscordClient.swiftSources/SwiftDisc/HighLevel/ComponentsBuilder.swiftSources/SwiftDisc/HighLevel/ViewManager.swiftSources/SwiftDisc/Models/MessageComponents.swiftSources/SwiftDisc/Voice/VoiceGateway.swift
✅ Files skipped from review due to trivial changes (1)
- Sources/SwiftDisc/HighLevel/ViewManager.swift
🚧 Files skipped from review as they are similar to previous changes (1)
- Sources/SwiftDisc/Models/MessageComponents.swift
Comment on lines
+838
to
+850
| // Searches messages within a guild. Requires READ_MESSAGE_HISTORY and MESSAGE_CONTENT intents. | ||
| public func searchGuildMessages(guildId: GuildID, query: String? = nil, authorId: UserID? = nil, minId: MessageID? = nil, maxId: MessageID? = nil, has: String? = nil, limit: Int? = nil, offset: Int? = nil) async throws -> [Message] { | ||
| var queryParams: [String] = [] | ||
| if let q = query { queryParams.append("content=\(q.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed) ?? q)") } | ||
| if let aid = authorId { queryParams.append("author_id=\(aid)") } | ||
| if let mid = minId { queryParams.append("min_id=\(mid)") } | ||
| if let mid = maxId { queryParams.append("max_id=\(mid)") } | ||
| if let h = has { queryParams.append("has=\(h)") } | ||
| if let l = limit { queryParams.append("limit=\(l)") } | ||
| if let o = offset { queryParams.append("offset=\(o)") } | ||
| let queryString = queryParams.isEmpty ? "" : "?\(queryParams.joined(separator: "&"))" | ||
| return try await http.get(path: "/guilds/\(guildId)/messages/search\(queryString)") | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Discord API GET /guilds/{guild.id}/messages/search response format 2025
💡 Result:
The Discord API endpoint GET /guilds/{guild.id}/messages/search returns a list of messages matching the search query within the specified guild. Messages exclude the 'reactions' key. Requires READ_MESSAGE_HISTORY permission and is restricted by the MESSAGE_CONTENT Privileged Intent. Response format (APIMessageSearchResult): - doing_deep_historical_index: boolean - Whether the guild is undergoing deep historical indexing. - documents_indexed?: number - Number of documents indexed in current operation (optional). - total_results: number - Total matching results. - messages: array of array of Omit<APIMessage, 'reactions'> - Nested array of matching messages (surrounding context no longer returned). - threads?: array of APIThreadChannel - Threads containing returned messages (optional). - members?: array of APIThreadMember - Thread members for joined threads (optional). If not yet indexed: 202 Accepted with { "message": "Index not yet available. Try again later", "code": 110000, "documents_indexed": 0, "retry_after": 2 }. Note: Search may return fewer than limit results for speed; total_results may be inaccurate during active message changes. Messages before Feb 24, 2026 may have indexing issues for 'gif' embed type. This matches 2025/2026 documentation with no indicated changes by 2026-04-13.
Citations:
- 1: https://discord-api-types.dev/api/discord-api-types-v10/interface/APIMessageSearchResult
- 2: https://docs.discord.com/developers/resources/message
- 3: https://discord.com/developers/docs/resources/message
- 4: https://discord-api-types.dev/api/discord-api-types-v10/interface/RESTGetAPIGuildMessagesSearchQuery
🏁 Script executed:
# Search for http.get implementation
rg "func get\(" Sources/SwiftDisc -A 5 -B 2Repository: M1tsumi/SwiftDisc
Length of output: 43
🏁 Script executed:
# Look for SearchMessagesResponse or similar wrapper types
rg "SearchMessages|APIMessageSearch" Sources/SwiftDiscRepository: M1tsumi/SwiftDisc
Length of output: 43
🏁 Script executed:
# Check for other similar endpoints that return wrapped responses
rg "struct.*Response.*Decodable" Sources/SwiftDisc -A 3Repository: M1tsumi/SwiftDisc
Length of output: 1149
🏁 Script executed:
# See if there are any patterns of flatMap being used for message responses
rg "messages\.flatMap|\.flatMap.*messages" Sources/SwiftDisc -B 2 -A 2Repository: M1tsumi/SwiftDisc
Length of output: 43
🏁 Script executed:
# Check the context around searchGuildMessages to understand what's already there
sed -n '835,855p' Sources/SwiftDisc/DiscordClient.swiftRepository: M1tsumi/SwiftDisc
Length of output: 1337
🏁 Script executed:
# Look for any Message-related response wrapper types
rg "messages.*\[\[Message\]\]|array.*Message" Sources/SwiftDisc -B 3 -A 3Repository: M1tsumi/SwiftDisc
Length of output: 43
🏁 Script executed:
# Check if there are any guild message endpoints that might handle similar responses
rg "getGuild|listGuild|searchGuild" Sources/SwiftDisc -A 10Repository: M1tsumi/SwiftDisc
Length of output: 27558
🏁 Script executed:
# Check the http.get method signature to see what it does
cat -n Sources/SwiftDisc/REST/HTTPClient.swift | sed -n '1,100p'Repository: M1tsumi/SwiftDisc
Length of output: 5336
Fix return type to handle nested message array from search endpoint.
Discord's GET /guilds/{guild.id}/messages/search endpoint returns a wrapped response object with messages, total_results, and other fields. The messages field is a nested array ([[Message]]), not a flat array. Decoding directly to [Message] will fail at runtime.
Define a response wrapper and flatten the nested array:
🔧 Suggested fix
+ public struct SearchMessagesResponse: Decodable, Sendable {
+ public let messages: [[Message]]
+ public let total_results: Int
+ }
+
public func searchGuildMessages(guildId: GuildID, query: String? = nil, authorId: UserID? = nil, minId: MessageID? = nil, maxId: MessageID? = nil, has: String? = nil, limit: Int? = nil, offset: Int? = nil) async throws -> [Message] {
var queryParams: [String] = []
// ... existing query building ...
let queryString = queryParams.isEmpty ? "" : "?\(queryParams.joined(separator: "&"))"
- return try await http.get(path: "/guilds/\(guildId)/messages/search\(queryString)")
+ let response: SearchMessagesResponse = try await http.get(path: "/guilds/\(guildId)/messages/search\(queryString)")
+ return response.messages.flatMap { $0 }
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Sources/SwiftDisc/DiscordClient.swift` around lines 838 - 850,
searchGuildMessages currently tries to decode the search endpoint directly to
[Message], but Discord returns a wrapper object whose messages field is
[[Message]]; create a response wrapper (e.g., GuildMessagesSearchResponse with
messages: [[Message]] and optional total_results/other fields) and change the
GET call to decode to that wrapper (use the existing http.get decoding path for
GuildMessagesSearchResponse), then flatten the nested array with
messages.flatMap { $0 } and return the flattened [Message] from
searchGuildMessages; keep the public signature returning [Message] and only
adjust the decoding/return inside the searchGuildMessages function.
Comment on lines
+79
to
+85
| private var components: [MessageComponent]? | ||
| public init() {} | ||
| public func label(_ t: String) -> LabelBuilder { var c = self; c.label = t; return c } | ||
| public func description(_ d: String) -> LabelBuilder { var c = self; c.description = d; return c } | ||
| public func components(_ comps: [MessageComponent]) -> LabelBuilder { var c = self; c.components = comps; return c } | ||
| public func build() -> MessageComponent { | ||
| .label(.init(label: label, description: description, components: components)) |
There was a problem hiding this comment.
Enforce the Label single-child contract in LabelBuilder.
Line [79] and Line [83] allow any array length, but Sources/SwiftDisc/Models/MessageComponents.swift documents Label.components as a single-child slot. This can emit structurally invalid modal payloads.
Suggested fix
public struct LabelBuilder {
private var label: String = ""
private var description: String?
- private var components: [MessageComponent]?
+ private var component: MessageComponent?
public init() {}
public func label(_ t: String) -> LabelBuilder { var c = self; c.label = t; return c }
public func description(_ d: String) -> LabelBuilder { var c = self; c.description = d; return c }
- public func components(_ comps: [MessageComponent]) -> LabelBuilder { var c = self; c.components = comps; return c }
+ public func component(_ comp: MessageComponent) -> LabelBuilder { var c = self; c.component = comp; return c }
public func build() -> MessageComponent {
- .label(.init(label: label, description: description, components: components))
+ .label(.init(label: label, description: description, components: component.map { [$0] }))
}
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Sources/SwiftDisc/HighLevel/ComponentsBuilder.swift` around lines 79 - 85,
LabelBuilder currently stores an array and exposes components(_ comps:
[MessageComponent]) allowing multiple children, violating the Label single-child
contract; change the builder to store a single MessageComponent (e.g., replace
private var components: [MessageComponent]? with a single optional component
property), change the setter signature components(_:) to accept one
MessageComponent (or add a new components(_ comp: MessageComponent) overload)
and update build() to pass that single component into .label(...); also add a
nil-check/validation so build() fails or logs clearly if no child was provided.
Comment on lines
+89
to
+123
| public struct RadioGroupBuilder { | ||
| private var customId: String = "" | ||
| private var options: [MessageComponent.RadioGroup.RadioOption] = [] | ||
| private var required: Bool? | ||
| public init() {} | ||
| public func customId(_ id: String) -> RadioGroupBuilder { var c = self; c.customId = id; return c } | ||
| public func option(label: String, value: String, description: String? = nil, isDefault: Bool? = nil) -> RadioGroupBuilder { | ||
| var c = self | ||
| c.options.append(.init(label: label, value: value, description: description, isDefault: isDefault)) | ||
| return c | ||
| } | ||
| public func required(_ r: Bool = true) -> RadioGroupBuilder { var c = self; c.required = r; return c } | ||
| public func build() -> MessageComponent { | ||
| .radioGroup(.init(custom_id: customId, options: options, required: required)) | ||
| } | ||
| } | ||
|
|
||
| public struct CheckboxGroupBuilder { | ||
| private var customId: String = "" | ||
| private var options: [MessageComponent.CheckboxGroup.CheckboxOption] = [] | ||
| private var minValues: Int? | ||
| private var maxValues: Int? | ||
| public init() {} | ||
| public func customId(_ id: String) -> CheckboxGroupBuilder { var c = self; c.customId = id; return c } | ||
| public func option(label: String, value: String, description: String? = nil, isDefault: Bool? = nil) -> CheckboxGroupBuilder { | ||
| var c = self | ||
| c.options.append(.init(label: label, value: value, description: description, isDefault: isDefault)) | ||
| return c | ||
| } | ||
| public func minValues(_ v: Int) -> CheckboxGroupBuilder { var c = self; c.minValues = v; return c } | ||
| public func maxValues(_ v: Int) -> CheckboxGroupBuilder { var c = self; c.maxValues = v; return c } | ||
| public func build() -> MessageComponent { | ||
| .checkboxGroup(.init(custom_id: customId, options: options, minValues: minValues, maxValues: maxValues)) | ||
| } | ||
| } |
There was a problem hiding this comment.
Add input validation to modal builders before constructing components.
These builders currently accept invalid state (e.g., empty customId on Line [90]/[107]/[126]/[139], empty options on Line [91]/[108], and unchecked min/max pairs on Line [118]-[119] and Line [148]-[149]). This will surface as downstream API errors instead of fail-fast local validation.
Suggested validation pattern (apply similarly to `CheckboxGroupBuilder`, `CheckboxBuilder`, `FileUploadBuilder`)
public struct RadioGroupBuilder {
private var customId: String = ""
private var options: [MessageComponent.RadioGroup.RadioOption] = []
private var required: Bool?
+ public enum ValidationError: Error { case missingCustomId, emptyOptions }
public init() {}
public func customId(_ id: String) -> RadioGroupBuilder { var c = self; c.customId = id; return c }
@@
public func required(_ r: Bool = true) -> RadioGroupBuilder { var c = self; c.required = r; return c }
- public func build() -> MessageComponent {
+ public func validate() throws {
+ if customId.isEmpty { throw ValidationError.missingCustomId }
+ if options.isEmpty { throw ValidationError.emptyOptions }
+ }
+ public func build() throws -> MessageComponent {
+ try validate()
.radioGroup(.init(custom_id: customId, options: options, required: required))
}
}Also applies to: 125-155
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Sources/SwiftDisc/HighLevel/ComponentsBuilder.swift` around lines 89 - 123,
RadioGroupBuilder.build and CheckboxGroupBuilder.build must validate builder
state before constructing MessageComponent: ensure customId is non-empty and
options is not empty; for CheckboxGroupBuilder also validate minValues/maxValues
(if both set, require 0 <= minValues <= maxValues and both <= options.count; if
only one set ensure it's within 0...options.count). Implement these checks
inside RadioGroupBuilder.build and CheckboxGroupBuilder.build (using
precondition, throw, or returning Result/optional per project convention) and
return/raise clear errors mentioning the field (customId, options, minValues,
maxValues) so invalid configs fail fast instead of reaching the API.
Comment on lines
+7
to
+12
| public enum VoiceEncryptionMode: String, Sendable { | ||
| case xsalsa20_poly1305 = "xsalsa20_poly1305" | ||
| case aead_aes256_gcm_rtpsize = "aead_aes256_gcm_rtpsize" | ||
| case aead_xchacha20_poly1305_rtpsize = "aead_xchacha20_poly1305_rtpsize" | ||
| case aead_aes256_gcm = "aead_aes256_gcm" | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Discord Voice Gateway docs: in Select Protocol (op 1), must data.modebe one ofReady.modes from op 2? Also confirm currently valid encryption modes and expected client behavior if a mode is unsupported locally.
💡 Result:
Yes, in the Discord Voice Gateway, for Select Protocol (op 1), the data.mode must be one of the modes listed in Ready.modes from the server's op 2 Ready payload. The client selects a supported encryption mode from the server's advertised list in op 2 and includes it in op 1. Currently valid encryption modes (as of 2026, post-deprecations) are: - aead_aes256_gcm_rtpsize (AEAD AES-256-GCM RTP-size; preferred when available) - aead_xchacha20_poly1305_rtpsize (AEAD XChaCha20-Poly1305 RTP-size; mandatory support required) - xsalsa20_poly1305_lite_rtpsize (XSalsa20-Poly1305-lite RTP-size; sometimes listed but deprecated in some contexts) Clients must support aead_xchacha20_poly1305_rtpsize. Older modes like xsalsa20_poly1305, xsalsa20_poly1305_lite, etc., are deprecated and rejected. If a client selects an unsupported mode locally (i.e., cannot encrypt/decrypt with it), or selects a mode not in the server's Ready.modes, the server will reject the connection with close code 4016 "Unknown encryption mode". The client cannot proceed with voice data transmission and should fail the connection, typically by closing the WebSocket or retrying with a supported mode. Libraries often log errors like "None of the provided encryption modes are supported" and prevent joining if no intersection exists between client capabilities and server modes.
Citations:
- 1: https://docs.discord.com/developers/topics/voice-connections
- 2: https://discord.com/developers/docs/topics/voice-connections
- 3: https://docs.discord.com/developers/topics/opcodes-and-status-codes
- 4: https://www.mintlify.com/discord/discord-api-docs/developers/topics/voice-connections
- 5: https://discord-api-types.dev/api/next/discord-api-types-voice/v8/enum/VoiceEncryptionMode
- 6: Voice: Discord new encryption modes not supported (aead_aes256_gcm_rtpsize) jagrosh/MusicBot#1851
- 7: https://docs.discord.food/topics/voice-connections
🏁 Script executed:
fd -t f "VoiceGateway.swift" --exec cat -n {} \;Repository: M1tsumi/SwiftDisc
Length of output: 6451
Validate encryption mode against server negotiation and implementation support.
Line 63 sends selectProtocol with any mode.rawValue, but only xsalsa20_poly1305 is implemented (as noted in lines 4–6). Additionally, there is no guard that mode.rawValue exists in the server-negotiated modes list (captured at line 56 from Ready.modes). Discord rejects unknown modes with close code 4016, breaking the voice connection.
Add validation before sending the payload:
Suggested fix
func selectProtocol(ip: String, port: UInt16, mode: VoiceEncryptionMode = .xsalsa20_poly1305) async throws {
guard let ws else { throw DiscordError.gateway("Voice socket not connected") }
+ guard mode == .xsalsa20_poly1305 else {
+ throw DiscordError.gateway("Voice encryption mode \(mode.rawValue) is not implemented yet")
+ }
+ guard modes.contains(mode.rawValue) else {
+ throw DiscordError.gateway("Voice encryption mode \(mode.rawValue) not offered by gateway")
+ }
struct SelectData: Codable { let address: String; let port: UInt16; let mode: String }
struct Select: Codable { let protocol_: String; let data: SelectData; enum CodingKeys: String, CodingKey { case protocol_ = "protocol"; case data } }
let payload = Payload(op: .selectProtocol, d: Select(protocol_: "udp", data: SelectData(address: ip, port: port, mode: mode.rawValue)))🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Sources/SwiftDisc/Voice/VoiceGateway.swift` around lines 7 - 12, Validate the
chosen VoiceEncryptionMode against the server-negotiated list and the library's
supported implementations before sending the selectProtocol payload: in the code
path that builds/sends selectProtocol (referencing the selectProtocol sender and
the Ready.modes value captured from the Ready event), check that the selected
mode.rawValue exists in Ready.modes and is one of the implemented modes
(currently only VoiceEncryptionMode.xsalsa20_poly1305); if it is not present or
not supported, do not send the payload and instead fail fast (return an
error/throw or log and close the voice setup) or choose a safe fallback mode,
ensuring the message to the server never contains an unsupported mode which
would trigger close code 4016.
Revert Voice Gateway version 8 upgrade and VoiceEncryptionMode enum to resolve Linux-specific segmentation fault in test execution. The Ubuntu CI consistently fails with signal 11 (SIGSEGV) during test execution, involving libcrypto.so.3, libssl.so.3, and FoundationNetworking. Windows and macOS builds pass successfully, indicating a Linux-specific issue with the voice-related changes that interact with crypto libraries. Changes reverted: - Voice Gateway version upgrade from v=4 to v=8 - VoiceEncryptionMode enum addition These changes will be re-introduced once the Linux FoundationNetworking/crypto library compatibility issue is resolved. The voice implementation remains marked as experimental in SwiftDisc. Other changes retained: - File Upload component (type 25) for modals - Search Guild Messages endpoint - Builder patterns for modal components Reference: GitHub Actions CI failure on ubuntu-latest
…zation Add support for Discord's premium subscription button style (style 10) to enable premium app monetization gating. Changes: - Add sku_id field to MessageComponent.Button struct: - Optional SKUID type for premium subscription SKU reference - Required when using PREMIUM_REQUIRED button style (style 10) - Backward compatible with existing button styles (optional parameter) - Add Style.premium case (value 10) to ButtonBuilder.Style enum: - Premium button style for subscription-gated interactions - Documented as introduced for Discord Premium Apps monetization - Add skuId(_:) method to ButtonBuilder: - Fluent API for setting SKU ID on premium buttons - Required when using premium button style - Update ButtonBuilder.build() to pass sku_id to Button initializer This enables developers to create buttons that require users to have an active premium subscription to interact, supporting Discord's Premium Apps monetization features introduced in 2025. Reference: Discord API changelog - Premium Apps: New Premium Button Style & Deep Linking URL Schemes
Add type-safe enums for Auto Moderation trigger types and action types to improve developer ergonomics and prevent invalid values. Changes: - Add AutoModerationRule.TriggerType enum: - keyword (1) - Keyword filtering - spam (3) - Spam detection - keywordPreset (4) - Keyword preset filtering - mentionSpam (5) - Mention spam detection - memberProfile (6) - Member profile keyword moderation (NEW) - Add AutoModerationRule.ActionType enum: - blockMessage (1) - Block the message - sendAlert (2) - Send alert to moderators - timeout (3) - Timeout the user - blockMemberInteraction (4) - Block member interactions (NEW) The trigger_type and action_type fields in AutoModerationRule remain as Int for backward compatibility with decoding, but developers can now use the enums for type-safe rule creation and comparison. This adds support for the MEMBER_PROFILE trigger type and BLOCK_MEMBER_INTERACTION action type introduced in Discord's Auto Moderation updates for member profile moderation and member quarantine features. Reference: Discord API changelog - Auto Moderation Member Profile Rule
…cation
Add support for modifying guild member flags via the Modify Guild Member endpoint.
Changes:
- Add flags parameter to modifyGuildMember() method:
- Optional Int type for member flags bitmask
- Allows setting member flags like did_rejoin, bypasses_verification, etc.
- Backward compatible (optional parameter, defaults to nil)
- Update Body struct to include flags field
- Pass flags to PATCH /guilds/{guild.id}/members/{user.id} endpoint
This completes support for the Modify Guild Member flags field permissions
introduced in Discord's API updates, allowing bots to modify member state flags
for moderation and verification purposes.
Reference: Discord API changelog - Modify Guild Member flags field permissions
Add comprehensive validation helpers for Discord message payloads to ensure
compliance with API limits and prevent errors before sending requests.
Changes:
- Add MessageValidation enum with validation helpers:
- validateContent(_:) - Checks message content length (max 2000 chars)
- validateEmbeds(_:) - Checks embed count (max 10)
- validateComponents(_:) - Checks component structure:
- Max 5 action rows per message
- Max 25 components per action row
- validateFileSize(_:isPremium:) - Checks file size:
- 25MB default, 500MB with premium
- validateMessage(content:embeds:components:) - Validates complete payload
- Add ValidationError enum with descriptive error cases:
- contentTooLong, tooManyEmbeds, tooManyActionRows
- tooManyComponentsInRow, fileTooLarge, missingRequiredField
- Add LocalizedDescription protocol for error descriptions
These helpers provide pre-send validation to prevent API errors from invalid
messages, improving developer ergonomics by catching issues before they reach
Discord's API.
Reference: Discord API documentation - Message Limits
…nformation
Add optional debug context field to all DiscordError cases to enable enhanced
error information in debug mode while maintaining backward compatibility.
Changes:
- Add debugContext parameter (String?, defaults to nil) to error cases:
- http(Int, String, debugContext: String?)
- api(message: String, code: Int?, debugContext: String?)
- decoding(any Error, debugContext: String?)
- encoding(any Error, debugContext: String?)
- network(any Error, debugContext: String?)
- gateway(String, debugContext: String?)
- validation(String, debugContext: String?)
- Update error descriptions to append debug context when present:
- Format: Error message - Context: {debugContext}
- Backward compatible (optional parameters default to nil)
- cancelled and unavailable cases unchanged (no context needed)
This enables developers to attach contextual information (request path, response
snippets, retry suggestions, etc.) to errors when debug mode is enabled, improving
debugging and error diagnosis without breaking existing code.
Reference: Developer ergonomics improvement - Enhanced Error Context
Add comprehensive error logging with context to high-level components that were previously silently swallowing errors, improving debuggability. Changes: - AutocompleteRouter: - Add error logging with path and option context for non-cancelled errors - Avoid noisy logs during normal typing by filtering cancelled errors - Previously silently swallowed all errors - ViewManager: - Add error logging for view cleanup failures with view id, channel, and message context - Add error logging for invalid regex patterns with view id and pattern context - Previously silently ignored cleanup errors and invalid regex errors - Collectors: - Add error logging for guild members stream errors with guild id context - Previously silently finished continuation on errors All errors now include contextual information (ids, paths, patterns) to aid debugging while avoiding noise from expected errors like user typing cancellation. This improves developer ergonomics by making errors visible and actionable without flooding logs with expected transient errors.
Improve error context format in HTTPClient to be consistent and developer-friendly. Changes: - Encoding errors now use format: Endpoint: METHOD path - Decoding errors now use format: Endpoint: METHOD path - Consistent format across all HTTP methods (GET, POST, PATCH, PUT, DELETE) - Makes error logs easier to parse and understand
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (2)
Sources/SwiftDisc/HighLevel/ComponentsBuilder.swift (2)
87-97:⚠️ Potential issue | 🟠 Major
LabelBuilderstill violates the single-child contract.Line [90] and Line [94] allow multiple children, while
MessageComponent.Labelis documented as single-child; Line [95]-Line [96] also allows missing child without fail-fast behavior.Suggested fix
public struct LabelBuilder { @@ - private var components: [MessageComponent]? + private var component: MessageComponent? @@ - public func components(_ comps: [MessageComponent]) -> LabelBuilder { var c = self; c.components = comps; return c } + public func component(_ comp: MessageComponent) -> LabelBuilder { var c = self; c.component = comp; return c } public func build() -> MessageComponent { - .label(.init(label: label, description: description, components: components)) + precondition(component != nil, "Label requires exactly one child component") + return .label(.init(label: label, description: description, components: component.map { [$0] })) } }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Sources/SwiftDisc/HighLevel/ComponentsBuilder.swift` around lines 87 - 97, LabelBuilder currently allows zero or multiple children via the components([MessageComponent]) API and build() doesn't enforce the single-child rule; update LabelBuilder so it enforces exactly one child: replace or overload components to accept a single MessageComponent (e.g. components(_ comp: MessageComponent) -> LabelBuilder) or, if keeping the array, validate that components contains exactly one element; then make build() fail-fast (use a precondition or throw) when no child or more than one child is present so MessageComponent.Label’s single-child contract is guaranteed (refer to the LabelBuilder struct, components(_:) method and build()).
100-166:⚠️ Potential issue | 🟠 MajorModal builders still skip required validation and can emit invalid components.
Line [112]-Line [165] builds components without checking required fields/ranges (
customId, options presence, and min/max bounds), so invalid state reaches API calls.Suggested validation pattern (apply to all modal builders here)
public struct RadioGroupBuilder { @@ + public enum ValidationError: Error { case missingCustomId, emptyOptions } + private func validate() throws { + if customId.isEmpty { throw ValidationError.missingCustomId } + if options.isEmpty { throw ValidationError.emptyOptions } + } - public func build() -> MessageComponent { + public func build() throws -> MessageComponent { + try validate() .radioGroup(.init(custom_id: customId, options: options, required: required)) } }public struct FileUploadBuilder { @@ + public enum ValidationError: Error { case missingCustomId, missingLabel, invalidLength } + private func validate() throws { + if customId.isEmpty { throw ValidationError.missingCustomId } + if label.isEmpty { throw ValidationError.missingLabel } + if let minLength, let maxLength, minLength > maxLength { throw ValidationError.invalidLength } + } - public func build() -> MessageComponent { + public func build() throws -> MessageComponent { + try validate() .fileUpload(.init(custom_id: customId, label: label, min_length: minLength, max_length: maxLength, required: required, placeholder: placeholder)) } }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Sources/SwiftDisc/HighLevel/ComponentsBuilder.swift` around lines 100 - 166, The build() methods in RadioGroupBuilder, CheckboxGroupBuilder, CheckboxBuilder, and FileUploadBuilder can produce invalid MessageComponent values because they don't validate required fields or numeric ranges; update each build() (RadioGroupBuilder.build, CheckboxGroupBuilder.build, CheckboxBuilder.build, FileUploadBuilder.build) to validate before returning: ensure customId is non-empty, RadioGroup/CheckboxGroup have at least one option, Checkbox option/default constraints are consistent, minValues and maxValues are within allowed bounds and min <= max, and FileUpload has a non-empty label and valid min_length/max_length (min <= max and non-negative); if validation fails, fail fast (use preconditionFailure or similar consistent error handling used elsewhere in the codebase) so invalid components never reach the API.
🧹 Nitpick comments (1)
Sources/SwiftDisc/Models/AutoModeration.swift (1)
15-21: Consider adding non-breaking typed accessors to complete the type-safety story.You introduced
ActionType/TriggerType, but the stored model fields remain rawInt. Adding computed wrappers keeps compatibility while making the API safer for consumers.♻️ Suggested non-breaking refinement
public struct Action: Codable, Hashable, Sendable { @@ public let type: Int public let metadata: Metadata? + + public var actionType: ActionType? { + ActionType(rawValue: type) + } } @@ public let trigger_type: Int @@ +public var triggerType: TriggerType? { + TriggerType(rawValue: trigger_type) +}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Sources/SwiftDisc/Models/AutoModeration.swift` around lines 15 - 21, Add non-breaking typed accessors to the AutoModeration model by introducing computed properties that wrap the raw Int storage and expose/accept ActionType and TriggerType values: implement getters that return ActionType?(rawValue: actionTypeRaw) and TriggerType?(rawValue: triggerTypeRaw) (or return a sensible default) and setters that assign the underlying Int fields from newValue.rawValue; keep the existing raw Int properties intact so Codable/database mappings stay unchanged and name the new accessors actionType and triggerType to reference the enums ActionType and TriggerType.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Sources/SwiftDisc/HighLevel/ComponentsBuilder.swift`:
- Around line 4-29: The build() method can emit a premium-style button without
skuId; add a validation in ButtonBuilder.build() that checks if style ==
Style.premium.rawValue and skuId == nil and fail fast with a clear error (e.g.,
preconditionFailure or throw a descriptive error) so you never construct
MessageComponent.button(.init(...)) for .premium without sku_id; reference
Style.premium, the style property, skuId property, and build() when adding this
guard.
In `@Sources/SwiftDisc/HighLevel/MessageValidation.swift`:
- Around line 84-88: Add a pre-check in validateFileSize to reject negative
sizes: before computing maxSize, verify size >= 0 and if not throw an
appropriate ValidationError (e.g., a new or existing case such as
ValidationError.invalidFileSize(size:) or a generic validation error) so
negative values fail fast; keep the existing
maxFileSizeBytes/maxFileSizePremiumBytes logic and the existing throw of
ValidationError.fileTooLarge for overly large files.
- Line 20: ValidationError currently conforms to a custom LocalizedDescription
protocol; replace that conformance with Swift's standard LocalizedError and
expose the message via the errorDescription property (e.g. implement var
errorDescription: String? { ... }) so the enum integrates with Swift error
tooling; update any other occurrences of the custom LocalizedDescription in this
file (including the other ValidationError cases around the later block and any
similar enums like DiscordError usage) to conform to LocalizedError and map
their existing localizedDescription implementations to errorDescription.
- Line 13: Update the constant maxComponentsPerRow in MessageValidation (public
static let maxComponentsPerRow) from 25 to 5 so the validator enforces Discord's
limit of 5 components per action row; locate the declaration of
maxComponentsPerRow and set its value to 5 and adjust any related tests or
validation logic that assumed 25.
- Around line 65-81: validateComponents currently filters non-actionRow items
away and silently allows invalid top-level components; change it to explicitly
reject any top-level MessageComponent that is not .actionRow. In
validateComponents(_:), iterate the original components array (not just filtered
actionRows), and for each component check if case .actionRow(let row) — if not,
throw a validation error (e.g., ValidationError.invalidTopLevelComponent or add
a suitable enum case) including the offending component type; keep the existing
maxActionRows and maxComponentsPerRow checks for .actionRow rows (use the
existing actionRowCount and row.components logic).
In `@Sources/SwiftDisc/Models/MessageComponents.swift`:
- Around line 67-77: The initializer currently defaults sku_id to nil which
allows callers rebuilding Button components to silently drop premium metadata;
change the init(signature) for MessageComponents (the
init(style:label:custom_id:url:disabled:sku_id:)) to make sku_id a non-optional
(or at least remove the nil default) so callers are forced to pass through the
existing SKUID value, and update call sites that reconstruct buttons (e.g., the
.button rebuild in ViewManager) to forward btn.sku_id into the initializer
rather than omitting it.
---
Duplicate comments:
In `@Sources/SwiftDisc/HighLevel/ComponentsBuilder.swift`:
- Around line 87-97: LabelBuilder currently allows zero or multiple children via
the components([MessageComponent]) API and build() doesn't enforce the
single-child rule; update LabelBuilder so it enforces exactly one child: replace
or overload components to accept a single MessageComponent (e.g. components(_
comp: MessageComponent) -> LabelBuilder) or, if keeping the array, validate that
components contains exactly one element; then make build() fail-fast (use a
precondition or throw) when no child or more than one child is present so
MessageComponent.Label’s single-child contract is guaranteed (refer to the
LabelBuilder struct, components(_:) method and build()).
- Around line 100-166: The build() methods in RadioGroupBuilder,
CheckboxGroupBuilder, CheckboxBuilder, and FileUploadBuilder can produce invalid
MessageComponent values because they don't validate required fields or numeric
ranges; update each build() (RadioGroupBuilder.build,
CheckboxGroupBuilder.build, CheckboxBuilder.build, FileUploadBuilder.build) to
validate before returning: ensure customId is non-empty,
RadioGroup/CheckboxGroup have at least one option, Checkbox option/default
constraints are consistent, minValues and maxValues are within allowed bounds
and min <= max, and FileUpload has a non-empty label and valid
min_length/max_length (min <= max and non-negative); if validation fails, fail
fast (use preconditionFailure or similar consistent error handling used
elsewhere in the codebase) so invalid components never reach the API.
---
Nitpick comments:
In `@Sources/SwiftDisc/Models/AutoModeration.swift`:
- Around line 15-21: Add non-breaking typed accessors to the AutoModeration
model by introducing computed properties that wrap the raw Int storage and
expose/accept ActionType and TriggerType values: implement getters that return
ActionType?(rawValue: actionTypeRaw) and TriggerType?(rawValue: triggerTypeRaw)
(or return a sensible default) and setters that assign the underlying Int fields
from newValue.rawValue; keep the existing raw Int properties intact so
Codable/database mappings stay unchanged and name the new accessors actionType
and triggerType to reference the enums ActionType and TriggerType.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 7ccb6fa8-b86e-42a6-902f-c2eee8ebb071
📒 Files selected for processing (6)
Sources/SwiftDisc/DiscordClient.swiftSources/SwiftDisc/HighLevel/ComponentsBuilder.swiftSources/SwiftDisc/HighLevel/MessageValidation.swiftSources/SwiftDisc/Internal/DiscordError.swiftSources/SwiftDisc/Models/AutoModeration.swiftSources/SwiftDisc/Models/MessageComponents.swift
🚧 Files skipped from review as they are similar to previous changes (1)
- Sources/SwiftDisc/Internal/DiscordError.swift
Comment on lines
+4
to
29
| public enum Style: Int { | ||
| case primary = 1 | ||
| case secondary = 2 | ||
| case success = 3 | ||
| case danger = 4 | ||
| case link = 5 | ||
| /// Premium button style (style 10). Requires sku_id for premium subscription gating. | ||
| /// Introduced for Discord Premium Apps monetization. | ||
| case premium = 10 | ||
| } | ||
| private var style: Int = Style.primary.rawValue | ||
| private var label: String? | ||
| private var customId: String? | ||
| private var url: String? | ||
| private var skuId: SKUID? | ||
| private var disabled: Bool? | ||
| public init() {} | ||
| public func style(_ s: Style) -> ButtonBuilder { var c = self; c.style = s.rawValue; return c } | ||
| public func label(_ t: String) -> ButtonBuilder { var c = self; c.label = t; return c } | ||
| public func customId(_ id: String) -> ButtonBuilder { var c = self; c.customId = id; return c } | ||
| public func url(_ u: String) -> ButtonBuilder { var c = self; c.url = u; return c } | ||
| public func skuId(_ id: SKUID) -> ButtonBuilder { var c = self; c.skuId = id; return c } | ||
| public func disabled(_ d: Bool = true) -> ButtonBuilder { var c = self; c.disabled = d; return c } | ||
| public func build() -> MessageComponent { | ||
| MessageComponent.button(.init(style: style, label: label, custom_id: customId, url: url, disabled: disabled)) | ||
| MessageComponent.button(.init(style: style, label: label, custom_id: customId, url: url, disabled: disabled, sku_id: skuId)) | ||
| } |
There was a problem hiding this comment.
Enforce premium button invariants in build().
Line [10] states premium requires sku_id, but Line [27]-Line [28] can emit .premium with skuId == nil, producing invalid payloads.
Suggested fix
public struct ButtonBuilder {
+ public enum ValidationError: Error { case premiumRequiresSkuId }
@@
- public func build() -> MessageComponent {
+ public func build() -> MessageComponent {
+ precondition(style != Style.premium.rawValue || skuId != nil, "Premium buttons require sku_id")
MessageComponent.button(.init(style: style, label: label, custom_id: customId, url: url, disabled: disabled, sku_id: skuId))
}
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Sources/SwiftDisc/HighLevel/ComponentsBuilder.swift` around lines 4 - 29, The
build() method can emit a premium-style button without skuId; add a validation
in ButtonBuilder.build() that checks if style == Style.premium.rawValue and
skuId == nil and fail fast with a clear error (e.g., preconditionFailure or
throw a descriptive error) so you never construct
MessageComponent.button(.init(...)) for .premium without sku_id; reference
Style.premium, the style property, skuId property, and build() when adding this
guard.
| /// Maximum number of action rows per message. | ||
| public static let maxActionRows = 5 | ||
| /// Maximum number of components per action row. | ||
| public static let maxComponentsPerRow = 25 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the current Discord API maximum number of message components allowed inside a single action row?
💡 Result:
The maximum number of message components allowed inside a single Discord API action row is 5. This applies to both legacy components (up to 5 buttons or 1 select menu) and Components V2 (explicitly stated as "Up to 5 interactive button components or a single select component" in the action row structure). While messages using the IS_COMPONENTS_V2 flag (1 << 15) allow up to 40 total components and more flexible layouts with containers, the per-action-row limit remains 5 child components.
Citations:
- 1: https://discord.com/developers/docs/components/reference
- 2: https://docs.discord.com/developers/components/reference
- 3: Raise limits for components in messages discord/discord-api-docs#7534
- 4: https://docs.discord.food/resources/components
🏁 Script executed:
#!/bin/bash
# Check if the file exists and inspect the relevant section
fd -t f "MessageValidation.swift" --exec cat -n {} \; | head -30Repository: M1tsumi/SwiftDisc
Length of output: 1679
Change maxComponentsPerRow from 25 to 5.
Discord API allows a maximum of 5 components per action row. The current value of 25 is too permissive and would allow invalid payloads to pass validation that the Discord API would reject.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Sources/SwiftDisc/HighLevel/MessageValidation.swift` at line 13, Update the
constant maxComponentsPerRow in MessageValidation (public static let
maxComponentsPerRow) from 25 to 5 so the validator enforces Discord's limit of 5
components per action row; locate the declaration of maxComponentsPerRow and set
its value to 5 and adjust any related tests or validation logic that assumed 25.
| public static let maxFileSizePremiumBytes = 500 * 1024 * 1024 | ||
|
|
||
| /// Errors that can occur during message validation. | ||
| public enum ValidationError: Error, LocalizedDescription { |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify whether custom LocalizedDescription is used elsewhere and whether LocalizedError is already used.
rg -n --type=swift '\bLocalizedDescription\b|\bLocalizedError\b|\berrorDescription\b|\blocalizedDescription\b'Repository: M1tsumi/SwiftDisc
Length of output: 1201
Replace custom LocalizedDescription with standard LocalizedError protocol.
ValidationError currently uses a custom LocalizedDescription protocol that mirrors Swift's standard LocalizedError. Using the standard protocol ensures proper integration with Swift's error handling ecosystem. Additionally, DiscordError elsewhere in the codebase already uses LocalizedError, creating an inconsistency.
Suggested fix
- public enum ValidationError: Error, LocalizedDescription {
+ public enum ValidationError: Error, LocalizedError {
@@
-/// Protocol for types that can provide localized error descriptions.
-public protocol LocalizedDescription {
- var errorDescription: String? { get }
-}Also applies to: 103-106
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Sources/SwiftDisc/HighLevel/MessageValidation.swift` at line 20,
ValidationError currently conforms to a custom LocalizedDescription protocol;
replace that conformance with Swift's standard LocalizedError and expose the
message via the errorDescription property (e.g. implement var errorDescription:
String? { ... }) so the enum integrates with Swift error tooling; update any
other occurrences of the custom LocalizedDescription in this file (including the
other ValidationError cases around the later block and any similar enums like
DiscordError usage) to conform to LocalizedError and map their existing
localizedDescription implementations to errorDescription.
Comment on lines
+65
to
+81
| public static func validateComponents(_ components: [MessageComponent]?) throws { | ||
| guard let components = components, !components.isEmpty else { return } | ||
| let actionRows = components.filter { if case .actionRow = $0 { return true } else { return false } } | ||
| let actionRowCount = actionRows.count | ||
| guard actionRowCount <= maxActionRows else { | ||
| throw ValidationError.tooManyActionRows(count: actionRowCount, max: maxActionRows) | ||
| } | ||
|
|
||
| for component in actionRows { | ||
| if case .actionRow(let row) = component { | ||
| let componentCount = row.components.count | ||
| guard componentCount <= maxComponentsPerRow else { | ||
| throw ValidationError.tooManyComponentsInRow(count: componentCount, max: maxComponentsPerRow) | ||
| } | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For Discord message payloads, must top-level components be action rows (type 1), with interactive components nested inside those rows?
💡 Result:
Yes, for Discord message payloads, top-level components in the components array must be action rows (type 1), with interactive components (buttons, select menus, etc.) nested inside those action rows. This applies to both legacy components (without IS_COMPONENTS_V2 flag, up to 5 action rows) and remains the structure for interactive components in the newer V2 system (with IS_COMPONENTS_V2 flag), where action rows serve as layout containers for interactive elements. In V2, other top-level components like text displays (type 10) or containers (type 17) can also be used directly, but interactive components still require nesting within action rows.
Citations:
- 1: https://docs.discord.com/developers/components/using-message-components
- 2: https://docs.discord.com/developers/components/reference
- 3: https://discord.com/developers/docs/components/reference
- 4: https://discordjs.guide/legacy/interactive-components/action-rows
- 5: https://www.mintlify.com/discord/discord-api-docs/developers/components/using-message-components
- 6: https://discord.js.org/docs/packages/discord-api-types/main/v10/APIActionRowComponent:Interface
- 7: https://discord.com/developers/docs/resources/message
🏁 Script executed:
# Find files related to MessageComponent
fd -t f -e swift | xargs grep -l "enum MessageComponent" | head -5Repository: M1tsumi/SwiftDisc
Length of output: 109
🏁 Script executed:
# Search for MessageComponent enum definition
rg "enum MessageComponent" -A 30Repository: M1tsumi/SwiftDisc
Length of output: 3290
🏁 Script executed:
# Search for any Discord API version flags or configuration
rg "IS_COMPONENTS_V2|APIVersion|apiVersion" -B 2 -A 2Repository: M1tsumi/SwiftDisc
Length of output: 2177
🏁 Script executed:
# Look for test cases related to validateComponents
fd -t f -e swift | xargs grep -l "validateComponents" | head -10Repository: M1tsumi/SwiftDisc
Length of output: 112
🏁 Script executed:
# Read the full MessageValidation.swift file
cat -n Sources/SwiftDisc/HighLevel/MessageValidation.swiftRepository: M1tsumi/SwiftDisc
Length of output: 5358
🏁 Script executed:
# Search for test files related to MessageValidation
fd -t f -e swift "Test|test" | xargs grep -l "validateComponents" 2>/dev/null | head -5Repository: M1tsumi/SwiftDisc
Length of output: 43
🏁 Script executed:
# Search for any documentation or comments about component validation rules
rg "top.level|toplevel" --type swift -B 3 -A 3Repository: M1tsumi/SwiftDisc
Length of output: 620
Reject non-ActionRow top-level message components during validation.
Line 67 filters only action rows and ignores other component types. Non-actionRow components (buttons, select menus, text inputs) should not appear at the top level of message component arrays per Discord API requirements, but the function silently passes invalid payloads containing these components.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Sources/SwiftDisc/HighLevel/MessageValidation.swift` around lines 65 - 81,
validateComponents currently filters non-actionRow items away and silently
allows invalid top-level components; change it to explicitly reject any
top-level MessageComponent that is not .actionRow. In validateComponents(_:),
iterate the original components array (not just filtered actionRows), and for
each component check if case .actionRow(let row) — if not, throw a validation
error (e.g., ValidationError.invalidTopLevelComponent or add a suitable enum
case) including the offending component type; keep the existing maxActionRows
and maxComponentsPerRow checks for .actionRow rows (use the existing
actionRowCount and row.components logic).
Comment on lines
+84
to
+88
| public static func validateFileSize(_ size: Int, isPremium: Bool = false) throws { | ||
| let maxSize = isPremium ? maxFileSizePremiumBytes : maxFileSizeBytes | ||
| guard size <= maxSize else { | ||
| throw ValidationError.fileTooLarge(size: size, max: maxSize) | ||
| } |
There was a problem hiding this comment.
Guard against negative file sizes.
validateFileSize currently accepts negative values, which should fail fast as invalid input.
Suggested fix
public static func validateFileSize(_ size: Int, isPremium: Bool = false) throws {
+ guard size >= 0 else {
+ throw ValidationError.missingRequiredField(field: "size")
+ }
let maxSize = isPremium ? maxFileSizePremiumBytes : maxFileSizeBytes
guard size <= maxSize else {
throw ValidationError.fileTooLarge(size: size, max: maxSize)
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| public static func validateFileSize(_ size: Int, isPremium: Bool = false) throws { | |
| let maxSize = isPremium ? maxFileSizePremiumBytes : maxFileSizeBytes | |
| guard size <= maxSize else { | |
| throw ValidationError.fileTooLarge(size: size, max: maxSize) | |
| } | |
| public static func validateFileSize(_ size: Int, isPremium: Bool = false) throws { | |
| guard size >= 0 else { | |
| throw ValidationError.missingRequiredField(field: "size") | |
| } | |
| let maxSize = isPremium ? maxFileSizePremiumBytes : maxFileSizeBytes | |
| guard size <= maxSize else { | |
| throw ValidationError.fileTooLarge(size: size, max: maxSize) | |
| } | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Sources/SwiftDisc/HighLevel/MessageValidation.swift` around lines 84 - 88,
Add a pre-check in validateFileSize to reject negative sizes: before computing
maxSize, verify size >= 0 and if not throw an appropriate ValidationError (e.g.,
a new or existing case such as ValidationError.invalidFileSize(size:) or a
generic validation error) so negative values fail fast; keep the existing
maxFileSizeBytes/maxFileSizePremiumBytes logic and the existing throw of
ValidationError.fileTooLarge for overly large files.
Comment on lines
+67
to
77
| /// SKU ID for premium button style (style 10). Required when using PREMIUM_REQUIRED button style. | ||
| /// Introduced for Discord Premium Apps monetization. | ||
| public let sku_id: SKUID? | ||
| public init(style: Int, label: String? = nil, custom_id: String? = nil, url: String? = nil, disabled: Bool? = nil, sku_id: SKUID? = nil) { | ||
| self.style = style | ||
| self.label = label | ||
| self.custom_id = custom_id | ||
| self.url = url | ||
| self.disabled = disabled | ||
| self.sku_id = sku_id | ||
| } |
There was a problem hiding this comment.
Prevent silent sku_id loss when reconstructing buttons.
With Line [70] defaulting sku_id to nil, call sites that rebuild buttons can silently drop premium metadata.
Example: Sources/SwiftDisc/HighLevel/ViewManager.swift (around Line [152]) rebuilds .button without forwarding btn.sku_id, which can break premium buttons after disable/transform flows.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Sources/SwiftDisc/Models/MessageComponents.swift` around lines 67 - 77, The
initializer currently defaults sku_id to nil which allows callers rebuilding
Button components to silently drop premium metadata; change the init(signature)
for MessageComponents (the init(style:label:custom_id:url:disabled:sku_id:)) to
make sku_id a non-optional (or at least remove the nil default) so callers are
forced to pass through the existing SKUID value, and update call sites that
reconstruct buttons (e.g., the .button rebuild in ViewManager) to forward
btn.sku_id into the initializer rather than omitting it.
Add test cases for the new debugContext parameter in DiscordError to ensure the error description format is correctly tested.
Change context separator from '|' to '-' to match expected test output format.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
Sources/SwiftDisc/REST/HTTPClient.swift (1)
263-264:⚠️ Potential issue | 🟠 MajorAvoid swallowing multipart JSON encoding failures.
Line 263 and Line 324 use
try?, which silently converts encoding errors intoniland can send incomplete payloads without surfacing an error.💡 Proposed fix
- let jsonData = try? jsonBody.map { try JSONEncoder().encode($0) } - req.httpBody = buildMultipartBody(jsonPayload: jsonData ?? nil, files: files, boundary: boundary) + let jsonData: Data? + do { + jsonData = try jsonBody.map { try JSONEncoder().encode($0) } + } catch { + throw DiscordError.encoding(error, debugContext: "Endpoint: POST \(path)") + } + req.httpBody = buildMultipartBody(jsonPayload: jsonData, files: files, boundary: boundary)- let jsonData = try? jsonBody.map { try JSONEncoder().encode($0) } - let body = buildMultipartBody(jsonPayload: jsonData ?? nil, files: files ?? [], boundary: boundary) + let jsonData: Data? + do { + jsonData = try jsonBody.map { try JSONEncoder().encode($0) } + } catch { + throw DiscordError.encoding(error, debugContext: "Endpoint: PATCH \(path)") + } + let body = buildMultipartBody(jsonPayload: jsonData, files: files ?? [], boundary: boundary)Also applies to: 324-326
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Sources/SwiftDisc/REST/HTTPClient.swift` around lines 263 - 264, The code currently swallows JSON encoding errors by using try? when encoding jsonBody (see jsonBody mapping into JSONEncoder and the call to buildMultipartBody that sets req.httpBody); change this to perform a throwing encode inside a do/catch (or propagate the error) so any encoding failure is surfaced instead of turning into nil — locate the JSONEncoder usage where jsonData is built and the second occurrence around lines that call JSONEncoder() and replace try? with explicit try and error handling, and ensure the function returns/throws a descriptive error (or logs and aborts building the multipart body) before calling buildMultipartBody so incomplete payloads are never sent.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Sources/SwiftDisc/REST/HTTPClient.swift`:
- Line 272: The decode error message in postMultipart and patchMultipart
references an undefined symbol method causing a compile error; fix by either
adding a method parameter to each function (matching the request(...) signature)
and using that parameter in the DiscordError.decoding debugContext, or more
simply change the debugContext to use the literal HTTP verb for each function
("POST" in postMultipart and "PATCH" in patchMultipart) so the string becomes
"Endpoint: POST \(path)" and "Endpoint: PATCH \(path)" respectively; update the
JSON decoding catch sites inside postMultipart and patchMultipart accordingly.
---
Outside diff comments:
In `@Sources/SwiftDisc/REST/HTTPClient.swift`:
- Around line 263-264: The code currently swallows JSON encoding errors by using
try? when encoding jsonBody (see jsonBody mapping into JSONEncoder and the call
to buildMultipartBody that sets req.httpBody); change this to perform a throwing
encode inside a do/catch (or propagate the error) so any encoding failure is
surfaced instead of turning into nil — locate the JSONEncoder usage where
jsonData is built and the second occurrence around lines that call JSONEncoder()
and replace try? with explicit try and error handling, and ensure the function
returns/throws a descriptive error (or logs and aborts building the multipart
body) before calling buildMultipartBody so incomplete payloads are never sent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 4d223844-3d5a-4fe6-89a4-72c8ab1a1a32
📒 Files selected for processing (4)
Sources/SwiftDisc/HighLevel/AutocompleteRouter.swiftSources/SwiftDisc/HighLevel/Collectors.swiftSources/SwiftDisc/HighLevel/ViewManager.swiftSources/SwiftDisc/REST/HTTPClient.swift
🚧 Files skipped from review as they are similar to previous changes (2)
- Sources/SwiftDisc/HighLevel/Collectors.swift
- Sources/SwiftDisc/HighLevel/ViewManager.swift
Add User-Agent header to identify SwiftDisc library usage to Discord, enabling tracking of how many bots use the library. Changes: - Add version constant (2.1.0) to DiscordConfiguration - Add User-Agent header to HTTPClient with format: DiscordBot (SwiftDisc, version, https://github.com/M1tsumi/SwiftDisc) - This allows Discord to track SwiftDisc adoption and usage statistics Reference: Discord API documentation on User-Agent headers
Add manual Equatable implementation to DiscordError to support error comparisons needed in AutocompleteRouter for filtering cancelled errors. This fixes compilation error: operator function '!=' requires that 'DiscordError' conform to 'Equatable'
Remove Equatable conformance from DiscordError and use pattern matching in AutocompleteRouter to avoid compilation errors with enum associated values. This fixes the compilation error: operator function '!=' requires that 'DiscordError' conform to 'Equatable'
Temporarily remove new test cases for debugContext parameter to isolate the root cause of CI fatalError. Original tests remain to verify basic functionality.
Fix scope errors where 'method' variable was not accessible in multipart POST/PATCH functions. Use hardcoded method strings instead. Changes: - postMultipart: Replace \(method) with POST - patchMultipart: Replace \(method) with PATCH This fixes compilation error: cannot find 'method' in scope
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores