Doug Roper

Looks like github returns `Retry-After` now! > When you have been limited, use the `Retry-After` response header to slow down. The value of the `Retry-After` header will always be an...

Ah, good point. So #2540 would only fix a subset of these issues. The majority of the failures I'm seeing are actually from `POST .../forks`, so I can at least...

Thanks for the review of #2540! [The document](https://docs.github.com/en/rest/guides/best-practices-for-integrators#dealing-with-secondary-rate-limits) also says: > When you have been limited, use the Retry-After response header to slow down. The value of the Retry-After header...

I'm also seeing this issue, but only under docker/linux. On the mac os host it works fine. This seems to be an issue with downstream dependencies. If I `npm shrinkwrap`...

@theinventor https://github.com/AudaxHealthInc/url-to-pdf-api/commit/41dc56c3c028b0dcc643cf83136e3e21b1500fd7 works, though that's a big hammer. @faliev's solution seems more targeted.

@gmethvin & @marcospereira, I could use your guidance here. Would be nice to nail this down before v2.

Thanks for the direction. I'd be interested in submitting a PR for the tolerant route, having written one already around my existing use of the play25 WSClient. Implementation is here:...

It just occurred to me that this causes precision loss in jackson-core as well when going from JSON => JSON (e.g. when pretty printing). Failing test in #731.

A simpler but more disruptive option might be to introduce a new `NumberType.FLOAT_UNKNOWN_PRECISION`.

> caller could check if parser can provide exact value or not. That'd work.