fix: normalize construction-channel fetch errors; reject wrong-type channel objects at setup (dpylogger-7/8)

initialize() previously let a bad construction channel id leak raw
discord.errors.NotFound/Forbidden/HTTPException past the documented
ValueError-only setup contract, and let an already-resolved non-TextChannel
object (Thread/VoiceChannel/ForumChannel) pass silently, later misrouting or
blackholing every send. Wrap the construction-channel fetch in the same
try/except as the settings path and type-check the resolved-object channel
path, mirroring the existing int-path guard.

Widened the normalization tuple to also catch discord.ClientException
(covers InvalidData), fixing dpylogger-9 opportunistically since it's the
same pattern.

Bump to v0.1.5.

Signed-off-by: disqualifier <dev@disqualifier.me>
This commit is contained in:
2026-07-02 17:19:03 -04:00
parent 1ea1cb5b63
commit 733306574f
3 changed files with 37 additions and 17 deletions
+11 -9
View File
@@ -10,13 +10,13 @@ live from `bot.settings` so it can change at runtime via a command.
`requirements.txt`:
```
dpy_logger @ git+ssh://git@git.rethinkstudios.io/rethink-public/dpy_logger.git@v0.1.4
dpy_logger @ git+ssh://git@git.rethinkstudios.io/rethink-public/dpy_logger.git@v0.1.5
```
Direct:
```bash
pip install "dpy_logger @ git+ssh://git@git.rethinkstudios.io/rethink-public/dpy_logger.git@v0.1.4"
pip install "dpy_logger @ git+ssh://git@git.rethinkstudios.io/rethink-public/dpy_logger.git@v0.1.5"
```
Requires `discord.py` (pulled transitively).
@@ -72,13 +72,15 @@ await bot.log.debug("noisy", log_to_file=False) # -> Discord only
## Errors
Resolution failures (unresolvable guild/channel, bad config, a non-text channel) raise
`ValueError` from `initialize()` a misconfigured logger should fail loudly at setup.
Underlying `discord` exceptions (`NotFound` / `Forbidden` / `HTTPException`) from
`fetch_guild`/`fetch_channel` are normalized to that `ValueError` so callers see one
error type. On a **per-call** send, neither resolution nor send failures propagate: they
fall back to the stdlib logger so a transient Discord failure (or a per-call `guild=`
that doesn't resolve) never breaks the caller's command.
Resolution failures (unresolvable guild/channel, bad config, a non-text channel — whether
passed as an id or as an already-resolved object) raise `ValueError` from `initialize()`
a misconfigured logger should fail loudly at setup. Underlying `discord` exceptions
(`NotFound` / `Forbidden` / `HTTPException` / `InvalidData` and other `ClientException`
subclasses) from `fetch_guild`/`fetch_channel` are normalized to that `ValueError` on every
resolution path (construction channel, per-guild settings lookup) so callers see one error
type. On a **per-call** send, neither resolution nor send failures propagate: they fall
back to the stdlib logger so a transient Discord failure (or a per-call `guild=` that
doesn't resolve) never breaks the caller's command.
## Construction contract