On Sun, Nov 3, 2024 at 9:00 PM jian he <jian.universal...@gmail.com> wrote: > The above Assert looks very wrong to me.
I can switch to Assert(false) if that's preferred, but it makes part of the libc assert() report useless. (I wish we had more fluent ways to say "this shouldn't happen, but if it does, we still need to get out safely.") > we can also use PG_INT32_MAX, instead of INT_MAX > (generally i think PG_INT32_MAX looks more intuitive to me) That's a fixed-width max; we want the maximum for the `int` type here. > expires_in > REQUIRED. The lifetime in seconds of the "device_code" and > "user_code". > interval > OPTIONAL. The minimum amount of time in seconds that the client > SHOULD wait between polling requests to the token endpoint. If no > value is provided, clients MUST use 5 as the default. > " > these two fields seem to differ from struct device_authz. Yeah, Daniel and I had talked about being stricter about REQUIRED fields that are not currently used. There's a comment making note of this in parse_device_authz(). The v1 code will need to make expires_in REQUIRED, so that future developers can develop features that depend on it without worrying about breaking currently-working-but-noncompliant deployments. (And if there are any noncompliant deployments out there now, we need to know about them so we can have that explicit discussion.) Thanks, --Jacob
