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:
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user