feat(bot): persistent giveaways with reaction entry

[LucasSantana-Dev]

Completes the giveaways Dyno-loss item (Wave 1 of the 2026-07-03 plan).

Replaces the vestigial in-memory activeGiveaways map:

• /giveaway start (prêmio, duração m/h/d, vencedores 1-10) — posts entry embed, bot adds 🎉; end/reroll by id. ManageGuild-gated.
• 🎉 reactions on an active giveaway create GiveawayEntry rows (unique per user; bots skipped).
• 60s finisher scheduler: draws distinct random winners, edits the embed, announces with scoped allowedMentions.
• Giveaway+GiveawayEntry models, migration 20260703053000_giveaways, GiveawayService.

Per-guild rows, nothing hard-coded.

Orchestrator-finished (agent draft recovered from a lint-staged stash): fixed EmbedBuilder.from typing, PermissionFlagsBits import source, duration parser ?? null, spec prisma factory mock (module-level capture), random-draw assertion, and ephemeral placement in the interactionReply wrapper.

Tests: shared 14, bot 23. Lint + full typecheck clean (pre-commit hook passed).

---

Summary by cubic

Adds persistent, per‑guild giveaways with 🎉 reaction entry and a 60s scheduler that draws, persists, updates the embed, and announces winners. Replaces the in‑memory map and tightens end/reroll, posting checks, and reliability.

• New Features

  • Prisma-backed Giveaway/GiveawayEntry; unique per-user entries via 🎉; /giveaway start (premio, duracao, vencedores, max 14d), /giveaway end, /giveaway reroll (Manage Guild).
  • giveawayScheduler runs every 60s; persists winners first, then edits the original embed (via setFields) and announces; starts on boot, stops on shutdown. Shared giveawayService and parseDuration in @lucky/shared/services.
  • Migration: run prisma migrate deploy to create giveaways and giveaway_entries.

• Bug Fixes

  • Guild-scoped end/reroll; reroll only on ended giveaways and preserves endedAt. /end on an already-ended giveaway reports winners without re-announcing; winners drawn with crypto.randomInt.
  • Safer posting/finalization: verify text channel and SendMessages; persist only after a successful post; scheduler still finalizes if the channel/message is missing; bot reactions ignored and no entries after end. Refactored shared helpers for end/reroll and added scheduler/service tests to improve reliability.

^{Written for commit 1b4df24. Summary will update on new commits.}

Summary by CodeRabbit

• New Features

  • Giveaways are now fully backed by persistent storage, so ending and rerolling work across restarts.
  • Added an automatic expiration workflow that finalizes giveaways and posts winner/no-valid-entries announcements.
  • Giveaway command inputs were updated: start uses premio, duracao, vencedores; end/reroll use id.

• Bug Fixes

  • 🎉 reactions now register entries via the persisted giveaway state and stop after a giveaway ends.
  • Improved safety for startup/shutdown and more resilient finalization when messages/channels aren’t available.

• Tests

  • Updated and expanded giveaway-related tests with improved mocking.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR moves giveaways to Prisma-backed persistence, adds a polling scheduler for due giveaways, and updates the giveaway command, reaction handling, and bot lifecycle hooks to use the shared giveaway service.

Changes

Database-backed Giveaway System

Layer / File(s)	Summary
Database schema and migration prisma/schema.prisma, prisma/migrations/20260703053000_giveaways/migration.sql	Adds Giveaway and GiveawayEntry models and the matching migration with indexes, uniqueness constraints, and a cascading foreign key.
GiveawayService implementation and tests packages/shared/src/services/GiveawayService.ts, packages/shared/src/services/GiveawayService.spec.ts, packages/shared/src/services/index.ts	Implements parseDuration, GiveawayData, and GiveawayService methods for creation, lookup, entry handling, ending, rerolling, due-giveaway queries, and message ID updates, then re-exports them and adds test coverage.
Scheduler and bot lifecycle wiring packages/bot/src/utils/general/giveawayScheduler.ts, packages/bot/src/handlers/clientHandler/service.ts, packages/bot/src/handlers/clientHandler/service.spec.ts, packages/bot/src/bot/start/initializer.ts	Adds a polling scheduler that finalizes ended giveaways, starts it on client ready, stops it during shutdown, and mocks it in the client handler tests.
Giveaway command rewrite packages/bot/src/functions/general/commands/giveaway.ts	Rewrites /giveaway start/end/reroll to use giveawayService and shared duration parsing, changes option names, and updates reply and message-edit behavior.
Reaction handler giveaway integration packages/bot/src/handlers/reactionHandler.ts, packages/bot/src/handlers/reactionHandler.spec.ts	Routes 🎉 reaction handling through giveawayService.getActiveByMessageId and addEntry, replacing in-memory state, with new test coverage.

Estimated code review effort: 4 (Complex) | ~60 minutes

Sequence Diagram(s)

sequenceDiagram
  participant User
  participant GiveawayCommand
  participant GiveawayService
  participant Prisma
  participant GiveawayScheduler
  participant DiscordChannel

  User->>GiveawayCommand: /giveaway start
  GiveawayCommand->>GiveawayService: create(giveawayData)
  GiveawayService->>Prisma: giveaway.create
  Prisma-->>GiveawayService: giveaway record
  GiveawayCommand->>DiscordChannel: send embed + react 🎉
  GiveawayCommand->>GiveawayService: updateMessageId(id, messageId)

  loop interval tick
    GiveawayScheduler->>GiveawayService: getEndedDue()
    GiveawayService->>Prisma: findMany(due giveaways)
    Prisma-->>GiveawayScheduler: giveaways
    GiveawayScheduler->>DiscordChannel: fetch/edit message
    GiveawayScheduler->>GiveawayService: endAndDraw(id)
    GiveawayService->>Prisma: update(winnerIds, endedAt)
  end

  User->>DiscordChannel: react 🎉
  DiscordChannel->>GiveawayService: getActiveByMessageId(messageId)
  GiveawayService->>Prisma: findFirst(active giveaway)
  DiscordChannel->>GiveawayService: addEntry(giveawayId, userId)
  GiveawayService->>Prisma: giveawayEntry.create

Loading

Possibly related PRs

• LucasSantana-Dev/Lucky#676: Updates the same bot shutdown lifecycle file and changes how long-lived client cleanup is handled.

Suggested labels: enhancement

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title is concise and accurately summarizes the main change: persistent giveaways with reaction-based entry in the bot.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/giveaways

---

_{Comment @coderabbitai help to get the list of available commands.}

[cubic-dev-ai]

9 issues found across 11 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[github-actions]

	Warnings
⚠️	Big PR — 1781 lines changed across 14 files. Consider splitting into smaller, reviewable chunks.
⚠️	User-facing change without a CHANGELOG.md update. Add a line under ## [Unreleased] if this should appear in release notes. (Or apply the skip-changelog label if this PR does not affect end users.)

Generated by 🚫 dangerJS against 1b4df24

[cubic-dev-ai]

0 issues found across 2 files (changes from recent commits).

<sub>Requires human review: Adds database migration for new giveaway tables; integrates new scheduler and reaction handling. Requires human review for migration safety and data integrity.

Re-trigger cubic</sub>

[coderabbitai]

Actionable comments posted: 6

♻️ Duplicate comments (1)

packages/bot/src/functions/general/commands/giveaway.ts (1)

147-226: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

Cross-guild end/reroll — see root-cause comment in GiveawayService.ts.

handleEnd/handleReroll call giveawayService.endById(giveawayId) / giveawayService.reroll(giveawayId) without passing interaction.guildId. Since the service methods don't scope lookups by guild (flagged in GiveawayService.ts lines 119-142), and the giveaway ID is publicly visible in the embed footer, this allows ending/rerolling giveaways belonging to a different guild. Once the service is updated to accept a guildId, these call sites need interaction.guildId threaded through.

Also applies to: 228-313

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/bot/src/functions/general/commands/giveaway.ts` around lines 147 -
226, `handleEnd` (and the matching `handleReroll` flow) currently call
`giveawayService.endById`/`reroll` with only the giveaway ID, which can target
giveaways from other guilds. Update these command handlers to thread
`interaction.guildId` into the service call, and make sure the service lookup in
`GiveawayService` is scoped by guild as well. Keep the same pattern in both
command paths so only giveaways from the current guild can be ended or rerolled.

🧹 Nitpick comments (3)

prisma/schema.prisma (1)

1265-1266: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Consider a composite index for the scheduler's due-giveaway query.

getEndedDue (shown in the relevant snippets) filters on both endsAt: { lte: now } and endedAt: null together. The current single-column indexes on guildId and endsAt each only cover one predicate; a composite @@index([endedAt, endsAt]) would let Postgres satisfy both filters from a single index scan, which matters once the giveaways table grows and the 60s scheduler polls it repeatedly.

♻️ Proposed index addition

   @@index([guildId])
   @@index([endsAt])
+  @@index([endedAt, endsAt])
   @@map("giveaways")

Also applies to: 1273-1274

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@prisma/schema.prisma` around lines 1265 - 1266, The scheduler’s due-giveaway
lookup in getEndedDue filters by both endedAt being null and endsAt being before
now, but the schema only has separate single-column indexes. Update the Giveaway
model in prisma/schema.prisma to add a composite index on endedAt and endsAt so
the query can use one index scan; keep the existing fields unchanged and place
the index alongside the Giveaway-related index definitions.

packages/bot/src/functions/general/commands/giveaway.ts (1)

228-249: 🚀 Performance & Scalability | 🔵 Trivial | 💤 Low value

Redundant round trip in handleReroll.

getById is called only to distinguish "not found" from "not ended yet," then reroll re-fetches the same record internally. Not a correctness issue, just an extra DB call on every reroll attempt; could be collapsed by having reroll return a discriminated result (e.g., 'not_found' | 'not_ended' | string[]).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/bot/src/functions/general/commands/giveaway.ts` around lines 228 -
249, In handleReroll, avoid the extra database round trip caused by calling
giveawayService.getById before giveawayService.reroll. Update the reroll flow so
reroll returns a discriminated result that can represent both missing giveaway
and not-ended states, and then use that result to choose the correct
interactionReply message. Keep the changes localized to handleReroll and
giveawayService.reroll so the command can distinguish outcomes without
preloading the giveaway separately.

packages/shared/src/services/GiveawayService.spec.ts (1)

1-250: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Missing test coverage for endById, getById, getEndedDue, updateMessageId.

Coverage exists for create, getActiveByMessageId, addEntry, getEntries, endAndDraw, and reroll, but not for endById (which has distinct idempotent no-redraw behavior when already ended) or getEndedDue/updateMessageId. Given endById's early-termination/idempotency logic and getEndedDue's filter are load-bearing for the scheduler, adding tests here would catch regressions early.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/shared/src/services/GiveawayService.spec.ts` around lines 1 - 250,
Coverage is missing for GiveawayService methods that have scheduler-critical and
idempotent behavior. Add spec cases in GiveawayService.spec.ts for endById,
getById, getEndedDue, and updateMessageId using the existing giveawayService and
mockPrisma setup; verify endById does not redraw or re-update an already ended
giveaway, getById returns the expected record lookup, getEndedDue filters by the
due-ended condition, and updateMessageId persists the new message ID through
prisma.giveaway.update.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/bot/src/functions/general/commands/giveaway.ts`:
- Around line 110-131: The giveaway posting flow in giveaway.ts rolls back the
database row for any failure in the try block, but if channel.send succeeds and
either msg.react or giveawayService.updateMessageId fails, the already-posted
Discord message is left orphaned. Update the error handling around the giveaway
send/react/update sequence so that the catch block distinguishes a failed post
from a post that already created msg; when msg exists, attempt to delete or
otherwise clean up that Discord message before deleting the giveaway record.
Also consider checking AddReactions permission before calling msg.react to avoid
entering the partial-failure path unnecessarily.

In `@packages/bot/src/utils/general/giveawayScheduler.ts`:
- Around line 116-122: The early return in giveawayScheduler’s channel
resolution path leaves non-`GuildText` giveaways unfinalized, so they keep
getting retried forever. Update the `giveawayScheduler` flow around the
`channel.type !== ChannelType.GuildText` check to still call `endAndDraw` before
returning, mirroring the existing `!this.client || !giveaway.messageId`
handling. Keep the debug log, but ensure the giveaway is finalized even when the
resolved channel cannot be used for announcement.
- Around line 66-171: The giveaway finalization logic in processEndedGiveaway is
using giveaway.winnerIds as if it were a nullable “already drawn” flag, so
endAndDraw is never reached for ended giveaways. Replace the winnerIds
nullish/boolean checks with an explicit “has winners already been drawn”
condition based on persisted state, and call giveawayService.endAndDraw before
building the embed or sending the announcement. After drawing, use the returned
winners consistently for the embed, announcement, and final log so the giveaway
is marked ended and won’t be reprocessed by getEndedDue().

In `@packages/shared/src/services/GiveawayService.ts`:
- Around line 119-142: endById and reroll currently operate only on giveawayId,
which allows cross-guild access if the ID is known. Update
GiveawayService.endById and GiveawayService.reroll to take guildId as an
additional parameter and scope the lookup/update to that guild, using
interaction.guildId from the giveaway.ts callers. Ensure the underlying
getById/endAndDraw path only returns or mutates records that match both
giveawayId and guildId so giveaways from other servers cannot be ended or
rerolled.
- Around line 1-3: The shared Prisma client is stale and is missing the giveaway
and giveawayEntry delegates used by GiveawayService, so the generated types no
longer match the service API. Regenerate or refresh the checked-in Prisma
artifacts under the shared generated client so getPrismaClient() returns a
client shape that includes those delegates, and verify the updated generated
client types compile cleanly with GiveawayService.
- Around line 91-153: Make giveaway finalization atomic in GiveawayService by
preventing concurrent callers from both entering endAndDraw(). The race is
between getEndedDue() and endById(), which can both compute winners and write
winnerIds/endedAt independently. Update the giveaway with an atomic claim first
(using an endedAt IS NULL condition on the prisma.giveaway write path) before
drawing winners, and only proceed to draw if the claim succeeds; reroll can
continue to operate only after endedAt is already set.

---

Duplicate comments:
In `@packages/bot/src/functions/general/commands/giveaway.ts`:
- Around line 147-226: `handleEnd` (and the matching `handleReroll` flow)
currently call `giveawayService.endById`/`reroll` with only the giveaway ID,
which can target giveaways from other guilds. Update these command handlers to
thread `interaction.guildId` into the service call, and make sure the service
lookup in `GiveawayService` is scoped by guild as well. Keep the same pattern in
both command paths so only giveaways from the current guild can be ended or
rerolled.

---

Nitpick comments:
In `@packages/bot/src/functions/general/commands/giveaway.ts`:
- Around line 228-249: In handleReroll, avoid the extra database round trip
caused by calling giveawayService.getById before giveawayService.reroll. Update
the reroll flow so reroll returns a discriminated result that can represent both
missing giveaway and not-ended states, and then use that result to choose the
correct interactionReply message. Keep the changes localized to handleReroll and
giveawayService.reroll so the command can distinguish outcomes without
preloading the giveaway separately.

In `@packages/shared/src/services/GiveawayService.spec.ts`:
- Around line 1-250: Coverage is missing for GiveawayService methods that have
scheduler-critical and idempotent behavior. Add spec cases in
GiveawayService.spec.ts for endById, getById, getEndedDue, and updateMessageId
using the existing giveawayService and mockPrisma setup; verify endById does not
redraw or re-update an already ended giveaway, getById returns the expected
record lookup, getEndedDue filters by the due-ended condition, and
updateMessageId persists the new message ID through prisma.giveaway.update.

In `@prisma/schema.prisma`:
- Around line 1265-1266: The scheduler’s due-giveaway lookup in getEndedDue
filters by both endedAt being null and endsAt being before now, but the schema
only has separate single-column indexes. Update the Giveaway model in
prisma/schema.prisma to add a composite index on endedAt and endsAt so the query
can use one index scan; keep the existing fields unchanged and place the index
alongside the Giveaway-related index definitions.

🪄 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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 27b331d2-f8d1-43c0-a444-29bf0a0b7d99

📥 Commits

Reviewing files that changed from the base of the PR and between e12e2e4 and 6a2638d.

📒 Files selected for processing (12)

• packages/bot/src/bot/start/initializer.ts
• packages/bot/src/functions/general/commands/giveaway.ts
• packages/bot/src/handlers/clientHandler/service.spec.ts
• packages/bot/src/handlers/clientHandler/service.ts
• packages/bot/src/handlers/reactionHandler.spec.ts
• packages/bot/src/handlers/reactionHandler.ts
• packages/bot/src/utils/general/giveawayScheduler.ts
• packages/shared/src/services/GiveawayService.spec.ts
• packages/shared/src/services/GiveawayService.ts
• packages/shared/src/services/index.ts
• prisma/migrations/20260703053000_giveaways/migration.sql
• prisma/schema.prisma

[cubic-dev-ai]

0 issues found across 1 file (changes from recent commits).

<sub>Requires human review: Large feature addition: database migration, new service, scheduler, and command changes. High risk and impact; requires human review.

Re-trigger cubic</sub>

[coderabbitai]

Actionable comments posted: 4

🧹 Nitpick comments (2)

packages/bot/src/functions/general/commands/giveaway.ts (2)

48-57: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Channel lookup relies on cache; fetch would be more robust, and the pattern is duplicated 3×.

interaction.client.channels.cache.get(...) returns undefined for uncached channels, incorrectly surfacing "Cannot access text channel" even when the channel exists. The same cast-and-check pattern is repeated verbatim in handleEnd (Lines 175-181) and handleReroll (Lines 264-270). Consider extracting a shared helper using channels.fetch(...) (with a catch) to reduce duplication and improve reliability for cold caches.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/bot/src/functions/general/commands/giveaway.ts` around lines 48 -
57, The channel lookup in giveaway command handling is too cache-dependent and
the same cast/check logic is duplicated across giveaway actions. Update the
channel retrieval in the giveaway flow to use the client channel fetch API with
error handling instead of relying on channels.cache.get, then centralize that
logic in a shared helper used by the giveaway command entry points and the
handleEnd and handleReroll paths so uncached channels are handled correctly and
the repeated pattern is removed.

---

112-118: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Tighten the post/react/persist sequence and avoid reaching into Prisma directly.

Two related concerns in this block:

• updateMessageId runs after msg.react, so any 🎉 reaction landing in that narrow window is dropped by the reaction handler (getActiveByMessageId looks up by messageId, which is still null). Persisting the message ID immediately after send() shrinks this window.
• prisma.giveaway.delete(...) is called directly from the command file, bypassing giveawayService. This leaks the Prisma schema into the command layer and duplicates cleanup logic that arguably belongs in the service.

♻️ Suggested restructure

     let msg
     try {
         msg = await channel.send({ embeds: [embed.toJSON()] })
-        await msg.react('🎉')
-        // Save message ID only after successful post
-        await giveawayService.updateMessageId(giveaway.id, msg.id)
+        // Save message ID immediately to minimize the window where early
+        // reactions can't be matched to this giveaway
+        await giveawayService.updateMessageId(giveaway.id, msg.id)
+        await msg.react('🎉')
     } catch (err) {
         // Clean up the orphan record if post fails
-        await prisma.giveaway.delete({ where: { id: giveaway.id } })
+        await giveawayService.delete(giveaway.id)

Add a delete(id) method to GiveawayService for this to work.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/bot/src/functions/general/commands/giveaway.ts` around lines 112 -
118, The giveaway post/react/persist flow in giveaway.ts should persist the
message ID immediately after channel.send and before msg.react so
getActiveByMessageId can resolve reactions sooner. Move the messageId update
into the giveawayService flow so the command only orchestrates send/react and
does not leave a window where reactions are dropped. Also replace the direct
prisma.giveaway.delete cleanup with a new giveawayService.delete(id) method and
use that in the catch block to keep Prisma access inside GiveawayService.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/bot/src/functions/general/commands/giveaway.ts`:
- Around line 147-217: The `/giveaway end` flow in handleEnd always posts the
winner announcement even when giveawayService.endById returns a giveaway that
was already ended. Update the service/command contract so handleEnd can tell
whether the giveaway was just ended now or was previously ended, and only edit
the message/send the “🎉 Congratulations...” channel announcement for the newly
ended case. Keep the existing giveaway message update logic in handleEnd, but
guard the re-announcement path using the result from endById.
- Around line 22-144: Make the reply behavior consistent in giveaway.ts by
adding ephemeral responses to the early validation and error paths in the
giveaway command flow. Update the interactionReply calls in the giveaway command
handler (around the initial guard checks, parseDuration validation,
channel/guild/permission checks, and the catch block after channel.send) so they
match the final success reply’s privacy behavior. Keep the change localized to
the giveaway command logic and use the existing interactionReply helper and
giveawayService flow.

In `@packages/bot/src/utils/general/giveawayScheduler.ts`:
- Line 3: The shared services export is broken because the generated
GiveawayService type output is missing, so `giveawayService` imported from
`@lucky/shared/services` cannot be fully resolved in `giveawayScheduler.ts`. Fix
the shared build/export pipeline so `packages/shared/dist/services/index.d.ts`
has a matching generated `GiveawayService` declaration and re-export, and verify
the `giveawayService` symbol is available with typings through
`@lucky/shared/services`.

In `@packages/shared/src/services/GiveawayService.ts`:
- Around line 92-142: Make giveaway ending preserve the original endedAt
timestamp during rerolls and return the persisted value from the update. Update
GiveawayService.endAndDraw so it can optionally skip setting endedAt for reroll
flows, have reroll call it without changing endedAt, and adjust endById to use
the result from prisma.giveaway.update (or its endedAt) instead of creating a
new Date() when rebuilding the GiveawayData.

---

Nitpick comments:
In `@packages/bot/src/functions/general/commands/giveaway.ts`:
- Around line 48-57: The channel lookup in giveaway command handling is too
cache-dependent and the same cast/check logic is duplicated across giveaway
actions. Update the channel retrieval in the giveaway flow to use the client
channel fetch API with error handling instead of relying on channels.cache.get,
then centralize that logic in a shared helper used by the giveaway command entry
points and the handleEnd and handleReroll paths so uncached channels are handled
correctly and the repeated pattern is removed.
- Around line 112-118: The giveaway post/react/persist flow in giveaway.ts
should persist the message ID immediately after channel.send and before
msg.react so getActiveByMessageId can resolve reactions sooner. Move the
messageId update into the giveawayService flow so the command only orchestrates
send/react and does not leave a window where reactions are dropped. Also replace
the direct prisma.giveaway.delete cleanup with a new giveawayService.delete(id)
method and use that in the catch block to keep Prisma access inside
GiveawayService.

🪄 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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: a4bd8b31-2cd2-4885-a8e5-069a9fc350a7

📥 Commits

Reviewing files that changed from the base of the PR and between 6a2638d and 8f0cee6.

📒 Files selected for processing (12)

• packages/bot/src/bot/start/initializer.ts
• packages/bot/src/functions/general/commands/giveaway.ts
• packages/bot/src/handlers/clientHandler/service.spec.ts
• packages/bot/src/handlers/clientHandler/service.ts
• packages/bot/src/handlers/reactionHandler.spec.ts
• packages/bot/src/handlers/reactionHandler.ts
• packages/bot/src/utils/general/giveawayScheduler.ts
• packages/shared/src/services/GiveawayService.spec.ts
• packages/shared/src/services/GiveawayService.ts
• packages/shared/src/services/index.ts
• prisma/migrations/20260703053000_giveaways/migration.sql
• prisma/schema.prisma

✅ Files skipped from review due to trivial changes (1)

• packages/bot/src/handlers/clientHandler/service.spec.ts

🚧 Files skipped from review as they are similar to previous changes (7)

• packages/shared/src/services/index.ts
• packages/bot/src/handlers/clientHandler/service.ts
• packages/bot/src/handlers/reactionHandler.spec.ts
• prisma/migrations/20260703053000_giveaways/migration.sql
• prisma/schema.prisma
• packages/bot/src/bot/start/initializer.ts
• packages/shared/src/services/GiveawayService.spec.ts

[coderabbitai]

Actionable comments posted: 2

♻️ Duplicate comments (1)

packages/bot/src/utils/general/giveawayScheduler.ts (1)

66-93: 🎯 Functional Correctness | 🔴 Critical | ⚡ Quick win

Critical: ?? still prevents endAndDraw from ever running — same unresolved bug as before.

giveaway here comes from giveawayService.getEndedDue(), which only returns records with endedAt: null. At that point winnerIds is the Prisma default [] — a defined, truthy value — not null/undefined. Since ?? only falls back on nullish values, giveaway.winnerIds ?? (await giveawayService.endAndDraw(...)) resolves to [] and never calls endAndDraw for real due giveaways:

• endedAt never gets persisted → getEndedDue() re-returns the same giveaway on every tick indefinitely.
• Announcements always show "no valid entries," regardless of actual entrants.

This is the exact defect raised in a prior review round; the fix (drop the winnerIds short-circuit entirely and always call endAndDraw) was not applied.

🐛 Proposed fix

     private async processEndedGiveaway(giveaway: {
         id: string
         channelId: string
         prize: string
         winnersCount: number
         messageId: string | null
-        winnerIds?: string[]
     }): Promise<void> {
         try {
-            // FIRST: Draw and persist winners up front so giveaway is finalized
-            // regardless of whether announcement succeeds. This ensures:
-            // 1. giveaway.endedAt is set immediately → won't re-process forever
-            // 2. We have the actual winners to announce, not an empty list
-            const winners =
-                giveaway.winnerIds ??
-                (await giveawayService.endAndDraw(
-                    giveaway.id,
-                    giveaway.winnersCount,
-                ))
+            // FIRST: Draw and persist winners up front so giveaway is finalized
+            // regardless of whether announcement succeeds.
+            const winners = await giveawayService.endAndDraw(
+                giveaway.id,
+                giveaway.winnersCount,
+            )

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/bot/src/utils/general/giveawayScheduler.ts` around lines 66 - 93,
The winner selection in processEndedGiveaway still short-circuits on
giveaway.winnerIds, so endAndDraw is never reached for ended giveaways because
winnerIds is an empty array instead of nullish. Update processEndedGiveaway to
always invoke giveawayService.endAndDraw for the due giveaway path and remove
the winnerIds fallback, so endedAt is persisted and the returned winners are the
actual drawn winners before the announcement logic runs.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/bot/src/functions/general/commands/giveaway.ts`:
- Around line 204-214: The giveaway end flow is using giveaway.endedAt in the
command handler to decide whether the giveaway was already ended, but endById()
sets that field for both previously-ended and newly-ended giveaways. Update
giveawayService.endById and the giveaway handler in giveaway.ts to return and
branch on an explicit alreadyEnded or endedNow flag instead of checking endedAt,
so the normal edit/announcement path only skips when the giveaway was already
ended before this call.

In `@packages/bot/src/utils/general/giveawayScheduler.spec.ts`:
- Around line 34-220: The giveaway scheduler in processEndedGiveaway is treating
an empty winnerIds array as already set, so endAndDraw gets skipped in the
normal pre-draw state. Update the winner selection logic to treat winnerIds: []
the same as unset, and add/adjust a spec case in giveawayScheduler.spec.ts that
covers the empty-array path alongside the existing winnerIds checks.

---

Duplicate comments:
In `@packages/bot/src/utils/general/giveawayScheduler.ts`:
- Around line 66-93: The winner selection in processEndedGiveaway still
short-circuits on giveaway.winnerIds, so endAndDraw is never reached for ended
giveaways because winnerIds is an empty array instead of nullish. Update
processEndedGiveaway to always invoke giveawayService.endAndDraw for the due
giveaway path and remove the winnerIds fallback, so endedAt is persisted and the
returned winners are the actual drawn winners before the announcement logic
runs.

🪄 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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 879299be-dfbf-4387-a0d6-29cb7dfac9c2

📥 Commits

Reviewing files that changed from the base of the PR and between 8f0cee6 and 1266f53.

📒 Files selected for processing (5)

• packages/bot/src/functions/general/commands/giveaway.ts
• packages/bot/src/utils/general/giveawayScheduler.spec.ts
• packages/bot/src/utils/general/giveawayScheduler.ts
• packages/shared/src/services/GiveawayService.spec.ts
• packages/shared/src/services/GiveawayService.ts

[cubic-dev-ai]

0 issues found across 1 file (changes from recent commits).

<sub>Requires human review: Adds database migration and new giveaway feature with business logic for drawing winners; requires human review for correctness and data integrity.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 4 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
95.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud