Fix/bug fixes

backup_prod_db.bash

@@ -0,0 +1,44 @@
+#!/bin/bash
+# AGENT INSTRUCTIONS: If editing the file, ensure that your model name is included here.
+# Generated by Anthropic Claude Sonnet 5 via Claude Code (CLI).
+# Makes a consistent point-in-time copy of generated/files/prod.db into
+# generated/backups/, using SQLite's online backup API so it's safe to run
+# while the bot container is up and writing to the DB.
+
+set -e
+
+DB_PATH="./generated/files/prod.db"
+BACKUP_DIR="./generated/backups"
+
+if [ ! -f "$DB_PATH" ]; then
+    echo "ERROR: $DB_PATH not found. Run this from the repo root." >&2
+    exit 1
+fi
+
+mkdir -p "$BACKUP_DIR"
+
+timestamp=$(date -u +"%Y%m%dT%H%M%SZ")
+backup_path="${BACKUP_DIR}/prod_${timestamp}.db"
+
+if command -v sqlite3 >/dev/null 2>&1; then
+    # The SQLite backup API (.backup) takes a consistent snapshot even while
+    # another process (the running container) holds the DB open, so the
+    # container does NOT need to be stopped for this.
+    sqlite3 "$DB_PATH" ".backup '${backup_path}'"
+else
+    echo "WARNING: sqlite3 CLI not found on this host — falling back to a raw file copy."
+    echo "This is only safe if the container is stopped (no concurrent writes)."
+    read -p "Container stopped? Continue with raw copy? [y/N] " confirm
+    if [ "$confirm" != "y" ] && [ "$confirm" != "Y" ]; then
+        echo "Aborted."
+        exit 1
+    fi
+    cp "$DB_PATH" "$backup_path"
+fi
+
+if [ ! -s "$backup_path" ]; then
+    echo "ERROR: Backup file is missing or empty: $backup_path" >&2
+    exit 1
+fi
+
+echo "Backup written to: $backup_path ($(du -h "$backup_path" | cut -f1))"

documentation/claude-reports/fix_review_2026-07.md

@@ -0,0 +1,215 @@
+<!--
+AGENT INSTRUCTIONS: If editing the file, ensure that your model name is included here.
+Bugs found by Anthropic Claude Fable 5 via Claude Code (CLI).
+Generated by Anthropic Claude Sonnet 5 via Claude Code (CLI).
+Description: Review of the 25 fix commits applied on fix/bug-fixes for the confirmed
+findings from bug_hunt_2026_07.md and bug_hunt_2026-07b.md. Eight parallel review
+angles were run against the diff to find regressions the fixes themselves introduced,
+plus adjacent issues the diff touched, moved, or sits near. The 10 bug-shaped
+candidates were each independently re-checked by bug-verifier subagents. Documentation
+only — no code was changed as part of this pass (findings are pending a follow-up fix
+pass).
+-->
+
+# InfiniBot Fix-Commit Review — July 2026
+
+**Branch:** `fix/bug-fixes`
+**Range reviewed:** `ca60550^..6421c2a` (25 commits, one per bug-hunt finding ID:
+D1, M1, H1, R1, R2, C1, J1, J2, E1, C2, M3, R4, B1, X1, DASH2, DASH3, DASH4, DASH5,
+L1, A1, J3, R3, X2, C3, X3).
+**Method:** Eight parallel review angles (correctness of each fix against its stated
+bug, regressions the fix could introduce, code the fix moved/touched without fixing,
+adjacent logic sharing the same file/function, cleanup opportunities, and a fresh
+top-to-bottom diff read) produced ~19 candidates. The 10 bug-shaped candidates were
+each independently re-verified by a `bug-verifier` subagent (static tracing against
+the repo). Documentation only — **no code was changed.**
+
+**Reported symptoms:** none — this was a review of the fix commits themselves, not a
+symptom-driven investigation.
+
+## Verification status
+
+All 10 bug-shaped candidates were independently re-checked by bug-verifier subagents
+(static tracing only). Result: **6 CONFIRMED, 4 refuted** (folded into "Investigated
+and refuted" below — no separate false-positive IDs assigned since these were
+candidates from this review pass, not carried-over findings).
+
+## Severity legend
+
+- **CRITICAL** — data loss / security / breaks the bot broadly
+- **HIGH** — breaks a common user-facing path
+- **MEDIUM** — edge case with real user impact, or perf that compounds at scale
+- **LOW** — cosmetic, latent, or cleanup
+
+---
+
+## The one real regression
+
+### FR1 — Autoban failure now welcomes the member it meant to ban
+**[VERIFIED: CONFIRMED]**
+**src/features/autobans.py:36**, **src/core/bot.py:692** (introduced by `bf9d0b7`, fix for X1)
+
+The X1 fix correctly stopped deleting the autoban entry when `member.ban()` fails
+(`Forbidden`), but it also changed `check_and_run_autoban_for_member`'s return value
+to `False` in that case (autobans.py:36-38). `on_member_join` uses that single
+boolean to mean "not an autoban target":
+
+```python
+if await autobans.check_and_run_autoban_for_member(member):
+    return
+# falls through to trigger_join_message + add_roles_for_new_member
+```
+
+So when the ban fails — most commonly because the bot lacks Ban Members permission —
+the join falls through to `trigger_join_message` and `add_roles_for_new_member`:
+**publicly welcoming and auto-roling the exact person an admin flagged for an
+autoban.** The pre-X1 code suppressed normal join processing even on a failed ban
+(it just also incorrectly deleted the entry). The fix collapsed two different
+meanings — "was this member banned" and "should join processing be suppressed" —
+into one boolean, and picked the wrong one to preserve.
+
+**Fix direction:** separate the two meanings. Either return a tri-state (banned /
+retry-pending / not-a-target), or simply return `True` whenever the member matched
+an autoban entry, regardless of whether the ban call itself succeeded.
+
+---
+
+## Confirmed, but pre-existing (the diff touched or relocated them)
+
+### FR2 — Filtered words aren't `re.escape`d
+**[VERIFIED: CONFIRMED — pre-existing, moved by `bc9c5a0` (M3)]**
+**src/features/moderation.py:290** (`_generate_profanity_regex_pattern`)
+
+An admin adding a filtered word like `(` or `[` through the dashboard — which
+validates only length and duplicates, not regex-safety — makes the pattern
+`re.compile` call at `_get_compiled_profanity_patterns` (moderation.py:319) raise.
+`functools.lru_cache` does not cache exceptions, so the same invalid word
+**re-raises on every message** in that guild, not just once. `LogIfFailure` around
+the moderation call swallows the exception, so profanity moderation is **silently
+disabled for that guild** until an admin removes the bad word — with no error
+surfaced anywhere. M3 relocated this code from an uncached per-message call into the
+cached helper but did not introduce the missing `re.escape`.
+**Fix direction:** `re.escape` the literal portions of `word` before wildcard
+substitution (or catch and skip unparseable words with a logged warning at add-time).
+
+### FR3 — The M3 cache doesn't remove the dominant per-message cost
+**[VERIFIED: CONFIRMED]**
+**src/features/moderation.py:353** (`str_is_profane`), **`Server.filtered_words`**
+
+For default-word-list guilds — the common case, since the storage optimization
+stores `[]` for "using the default list" — every moderated message still
+constructs a fresh `Server` object, whose `filtered_words` getter calls
+`read_txt_to_list("default_profane_words.txt")`: an **uncached disk read + parse**,
+executed before the M3 pattern cache is even consulted. The regex-compile cost M3
+targeted is real but secondary to this read for the majority of guilds.
+**Fix direction:** cache the parsed default word list (module-level, read once) so
+the M3 pattern cache actually sees a stable, hashable key on the hot path.
+
+### FR4 — Orphaned-guild cleanup blocks the event loop
+**[VERIFIED: CONFIRMED]**
+**src/core/db_manager.py:1172** (`daily_database_maintenance`)
+
+Its siblings in the same function — `get_database().checkpoint` (line 1136),
+`optimize_database(throttle=True)` (line 1145), `stored_messages.cleanup_db` (line
+1156) — are all offloaded via `asyncio.to_thread`, with a comment explaining exactly
+why ("blocking phases run in a worker thread... would otherwise freeze the bot").
+`cleanup_orphaned_guild_entries(...)` at line 1172 is called directly on the event
+loop. It used to *have* to run synchronously (shared pooled connection + a SQLite
+TEMP table, per the D1 fix), but D1's `pinned_connection` change removed that
+constraint — the old justifying comment for keeping it off-thread was deleted along
+with the bug, and nothing was moved back onto `to_thread` to match its siblings.
+**Fix direction:** wrap the line-1172 call in `await asyncio.to_thread(...)` like the
+other three phases.
+
+### FR5 — Autoban "already banned?" check paginates the entire ban list
+**[VERIFIED: CONFIRMED]**
+**src/features/dashboard.py:4729** (autoban-add flow)
+
+The inline comment at dashboard.py:4725-4726 claims "nextcord doesn't provide a
+direct method to check if a user is banned through an ID" and falls back to
+`async for ban_entry in interaction.guild.bans(): ...` — paginating the *entire*
+ban list on every autoban addition. This is incorrect: `await
+guild.fetch_ban(nextcord.Object(id=user_id))` is a single REST call that raises
+`NotFound` when the user isn't banned, and it's already used elsewhere in this exact
+codebase (`src/features/options_menu/ban_button.py:70`). On a server with thousands
+of bans, adding one autoban entry costs seconds of paginated REST calls instead of
+one.
+**Fix direction:** replace the `async for` loop with a
+`try: await guild.fetch_ban(...) / except nextcord.NotFound: pass` pair.
+
+### FR6 — Reaction-role emoji/role misalignment on role deletion
+**[VERIFIED: CONFIRMED, narrow window]**
+**src/features/reaction_roles.py:263** (`create_reaction_role`, Custom flow)
+
+In the Custom flow, `roles` is built by filtering `new_roles_str` against
+`interaction.guild.roles` — so a role deleted between validation and creation is
+silently dropped from the list. The parallel `emojis` list (line 265) is built
+independently from the raw `roles_str` and is **not** filtered, so if any role in
+the middle of the list was deleted, the two lists desync and emoji[i] no longer
+corresponds to roles[i] for every entry after the gap. This is reachable because an
+earlier validation pass runs, then the flow waits on a modal for up to 5 minutes
+(plenty of time for a role to be deleted), after which `create_reaction_role`
+re-parses the original raw string rather than re-validating against current guild
+state. Pre-existing indexing logic in `create_reaction_role`; R3 only changed the
+mention-parsing regex used to build `new_roles_str`, not this filtering asymmetry.
+**Fix direction:** filter `roles` and `emojis` together (zip, filter, unzip) instead
+of filtering `roles` alone.
+
+---
+
+## Cleanup opportunities (verified real, lower stakes)
+
+- **FR7.** `SelectView` raises `ValueError` on an empty options list
+  (`src/components/ui_components.py:332`). DASH4 added proper empty-state handling
+  at 2 call sites (the channel-select pages), but roughly 5 other `SelectView` call
+  sites across the dashboard still carry their own ad-hoc guards against the same
+  crash. The empty-state handling belongs inside the shared `SelectView` component
+  so new pages can't regress it.
+- **FR8.** The R2 fix (using the field index as the select option value, plus an
+  `option_roles` map to resolve it) was pasted identically into both
+  `RoleMessageButton_Single` and `RoleMessageButton_Multiple`
+  (`src/features/role_messages.py:25` and `:122`). The two classes are near-clones;
+  any future encoding fix to this mechanism has to be made twice, and it's easy to
+  update one and forget the other.
+- **FR9.** `extract_role_id` (`src/features/reaction_roles.py:12`) is roughly the
+  5th independent implementation of `<@&id>` mention parsing in the codebase.
+  Worth extracting to one shared utility so fixes like R3 (spacing-independent
+  parsing) don't need to be re-discovered per copy.
+- **FR10.** `src/features/action_logging.py:467` and `:489` still use bare literals
+  (`> 9`, `[0:8]`, `>= 10`) for the embed-count limit right next to the new
+  `MAX_EMBEDS_PER_MESSAGE` constant A1 introduced. If the 10-embed limit logic ever
+  changes, these will silently drift out of sync with the constant.
+
+Minor items noted but cut for being below the 10-finding review cap: the DM-send
+try/except-Forbidden boilerplate repeated at roughly 7 call sites, a duplicated
+`go_back` closure (`dashboard.py:656` and `:1860`), `raise Exception` used as a
+goto-style control-flow mechanism in `reaction_roles.py:165` and `:175`, and the
+profanity `functools.lru_cache(maxsize=256)` sizing (untuned, no data behind the
+number).
+
+---
+
+## Investigated and refuted (no action needed)
+
+- **`start_scheduler()` re-running on `on_ready` re-fires (C3 concern).** Run times
+  are grid-aligned to wall clock (e.g. `:00/:15/:30/:45`), so a reconnect that
+  re-triggers scheduler startup converges on the same boundary as the original
+  schedule rather than drifting or duplicating runs. No starvation or duplicate-run
+  risk.
+- **The R4 reorder (message fetched before member).** Net *reduction* in REST calls
+  versus the prior code, which fetched both unconditionally regardless of whether
+  the early-exit conditions were met. Not a regression.
+- **`get_channel`/`get_message` lacking the X3 string-ID coercion.** Every call site
+  was traced; all already pass native `int`s. `utils.get_member`'s new tolerance for
+  string IDs (X3) is a hardening improvement for future callers, not a fix for a
+  currently-reachable bug elsewhere.
+- **`asci_to_emoji` mishandling counts of "11" or more.** Option counts are
+  structurally capped at 10 in two independent places (the select-menu builder and
+  the Custom/Numbers type validation), so the theoretical double-digit-overflow path
+  is unreachable.
+
+---
+
+*Generated by Anthropic Claude Fable 5 and documented by Sonnet 5 via Claude Code (CLI). 
+Documentation-only pass — no source files were modified. Line references are against 
+`fix/bug-fixes` at `6421c2a`; verify against current tree before fixing.*

github-pages-site/docs/core-features/logging.md

@@ -37,16 +37,16 @@ InfiniBot logs the following activities, categorized into three main types:
 
 ### Member Events
 
-| Event Type         | Description                          |
-|--------------------|--------------------------------------|
-| Nickname Changes   | Tracks changes to member nicknames.  |
-| Role Changes       | Logs updates to member roles.        |
+| Event Type         | Description                                      |
+|--------------------|---------------------------------------------------|
+| Nickname Changes   | Tracks changes to member nicknames. (best-effort — see below) |
+| Role Changes       | Logs updates to member roles. (best-effort — see below)       |
 
 ### Moderation Events
 
 | Event Type         | Description                          |
 |--------------------|--------------------------------------|
-| Member Timeouts    | Logs when a member is timed out.     |
+| Member Timeouts    | Logs when a member is timed out. (best-effort — see below) |
 | Member Bans        | Tracks bans and unbans of members.   |
 | Member Kicks       | Logs when a member is kicked.        |
 
@@ -93,6 +93,13 @@ Removing message data from InfiniBot's database does NOT delete the message from
 
 For more information on InfiniBot's data handling and retention policies, please refer to our [Privacy Policy]({% link docs/legal/privacy-policy.md %}).
 
+## Member Event Limitations
+
+Nickname changes, role changes, and timeouts can only be logged for members InfiniBot currently has cached. InfiniBot does not proactively load the full member lists, so a member who hasn't recently interacted with the server may not be cached, and a change to that member will silently go unlogged.
+
+After a member interacts with the server or updates their information (nickname, roles, etc.), they will be cached by InfiniBot, and subsequent changes to that member can be logged.
+
+
 ## Tips for Effective Logging
 
 - Set up a dedicated logging channel separate from your main admin channel and disable notifications for this channel to minimize distractions.

github-pages-site/docs/messaging/generic-replacements.md

@@ -22,15 +22,15 @@ Generic replacements can be used in embeds, join/leave messages, role messages,
 - `@username` - Shows the member's username
 - `@displayname` - Shows the member's display name
 - `@id` - Shows the member's Discord ID
-- `@joindate` - Shows when the member joined the server
-- `@accountage` - Shows how old the member's Discord account is
+- `@joindate` - Shows when the member joined the server (best-effort; see below)
+- `@accountage` - Shows how old the member's Discord account is (best-effort; see below)
 
 ## Server Replacements
 
 - `@server` - Shows the server name
 - `@serverid` - Shows the server's Discord ID
 - `@membercount` - Shows the total number of members in the server
-- `@owner` - Shows the server owner's display name
+- `@owner` - Shows the server owner's display name (best-effort; see below)
 
 ## Time and Date Replacements
 
@@ -55,8 +55,16 @@ This would appear as:
 Welcome @discord-user to Awesome Server! Please check out #rules to get started!
 ```
 
+## Best-Effort Replacements
+
+{: .warning }
+A few replacements depend on information Discord may not have handed InfiniBot at the moment the message is sent. When that information isn't available, the placeholder is replaced with the literal text **`Unknown`** rather than being left in place.
+
+This behavior is a deliberate trade-off: InfiniBot avoids requesting full member lists for large servers, since doing so is slow and rate-limited by Discord. In practice these replacements resolve correctly the majority of the time in smaller and moderately sized servers, where the entire member list is cached. For large servers, these fields frequently can't be resolved. See also the [Logging]({% link docs/core-features/logging.md %}) page, which has the same underlying limitation.
+
 ## Usage Notes
 
 - These replacements work in most text-based messages sent by InfiniBot
 - Replacements are case-sensitive
+- The user replacements (`@mention`, `@username`, `@displayname`, `@id`, `@joindate`, `@accountage`) only apply where a specific user is associated with the message. In contexts with no such user (for example, a role message or reaction role embed) these placeholders are left untouched and will appear literally in the message
 - If a replacement can't be processed, it will remain as plain text or appear as "Unknown"

release_prod.bash

@@ -0,0 +1,30 @@
+#!/bin/bash
+# AGENT INSTRUCTIONS: If editing the file, ensure that your model name is included here.
+# Generated by Anthropic Claude Sonnet 5 via Claude Code (CLI).
+# Prod release playbook: back up the DB, tag the current image as a rollback
+# point, then rebuild and restart the container. Pass --no-cache to force a
+# clean Docker build (forwarded to build.bash).
+#
+# Rollback afterwards: ./rollback_prod.bash
+
+set -e
+
+echo "==> Step 1/3: Backing up the database..."
+bash ./backup_prod_db.bash
+
+echo ""
+echo "==> Step 2/3: Tagging current image as rollback point..."
+if docker image inspect infinibot:latest >/dev/null 2>&1; then
+    docker tag infinibot:latest infinibot:rollback
+    echo "Tagged infinibot:latest -> infinibot:rollback"
+else
+    echo "No existing infinibot:latest image found — nothing to tag (first deploy?)."
+fi
+
+echo ""
+echo "==> Step 3/3: Rebuilding and restarting the container..."
+bash ./rebuild_and_run.bash -d "$@"
+
+echo ""
+echo "Release complete."
+echo "If something's wrong, roll back in under a minute with: ./rollback_prod.bash"