What happened?
In the last few days, I've noticed the webhooks API (List deliveries for an app webhook) has started returning big integers ids. For example, previously I'd get back an id like 199287304442, now I get back one like 3804004623172239366.
This is problematic for octokit, since it does a JSON.parse of the response body, which does not natively handle big integers. So in JavaScript the value I get is 3804004623172239400 due to loss of precision. Because these values are wrong, I can't use them for subsequent API calls, e.g. to redeliver a failed delivery.
This can be potentially worked around by manually wiring up requests and JSON processing, but then I can't fully use octokit. I suspect octokit could fix this by adopting something like json-bigint, though that would likely have downstream implications.
Versions
Octokit.js v7.0.6, Node.js v22.21.1
Relevant log output
Code of Conduct
What happened?
In the last few days, I've noticed the webhooks API (List deliveries for an app webhook) has started returning big integers ids. For example, previously I'd get back an id like
199287304442, now I get back one like3804004623172239366.This is problematic for octokit, since it does a JSON.parse of the response body, which does not natively handle big integers. So in JavaScript the value I get is
3804004623172239400due to loss of precision. Because these values are wrong, I can't use them for subsequent API calls, e.g. to redeliver a failed delivery.This can be potentially worked around by manually wiring up requests and JSON processing, but then I can't fully use octokit. I suspect octokit could fix this by adopting something like json-bigint, though that would likely have downstream implications.
Versions
Octokit.js v7.0.6, Node.js v22.21.1
Relevant log output
Code of Conduct