> On Apr 1, 2026, at 07:50, Jacob Champion <[email protected]>
> wrote:
>
> On Tue, Mar 31, 2026 at 10:45 AM Zsolt Parragi
> <[email protected]> wrote:
>> I didn't want to write "print-poll-counts" and "print-trace" as those
>> are just longer, while simply writing "plugin-errors" without print
>> also seemed wrong. Maybe it could be "plugin-debug" instead, that
>> sounds good even withour print?
>
> I like `plugin-errors`, actually -- "I want to debug these plugin
> errors." Adding -debug to the name doesn't seem great to me, since
> it's clear from the context that we're debugging.
>
> `dos-retry` still doesn't quite convey what we're doing...
> `dos-endpoint` maybe? `busy-loop`? The unsafe aspect is the resource
> consumption...
>
> To keep the brainstorming going, I chose the following for v3, but
> they're by no means settled:
>
> - http
> - trace
> - dos-endpoint
> - call-count
> - plugin-errors
>
>>> I have a sample patch locally for these suggestions, if you'd like.
>>
>> I can create a patch with these updates tomorrow, but if you already
>> have it, that might be easier/quicker.
>
> In the interest of time I've attached it as a single patch, but the
> range-diff is rough to read. If you'd like, I can split the code
> motion apart from the logical changes tomorrow, to see if it helps
> with review.
>
> --Jacob
> <since-v2.nocfbot.diff><v3-0001-Split-PGOAUTHDEBUG-UNSAFE-into-multiple-options.patch>
Looks like this patch helps reduce uninteresting debug logs. Overall, it looks
good to me. I just have a couple of small comments.
1
```
+#define OAUTHDEBUG_UNSAFE_HTTP (1<<0)
```
Since the flags are defined as uint32, does it make sense to define these flag
constants as ((uint32) 1 << 0)?
2 oauth_get_debug_flags() reparses PGOAUTHDEBUG every time it is called, which
feels a bit unnecessary. But I don't think this is a big deal, since these
debug options should never be enabled in production.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
