@agitter, @dhimmel

What do you think about this proposal?

@dhimmel is something wrong with this patch?

Sorry about the slow reply. My bad.

I'm in favor of setting a timeout on requests that we've seen can get stuck, especially those that timeout rather than fail immediately for bad identifiers. Not sure if this is more than just the ISBN requests.

Don't really think we need to make the timeout configurable at the CLI level just yet nor do we need to pass timeout to everything that makes requests. Possibly we do want some global requests config, but I'm not sure this PR does that in a scalable way.

So in the interest of quickly merging, can we reduce this PR (or a new one) to just address the requests that are known to timeout?

I think giving good defaults and a mechanism to alllow the user control is the cleanest way to account for all unexpected edge cases:

• user has a 56kb modem, no problem, just increase timeout to 5 min.
• realtime editing (i.e. Quarto integration #332), just enable cahing and set a real low timeout…
• everything in between.

I also think it's cleaner to upgrade the interface that makes requests to handle this case and it would be more cumbersome to track where are all the special cases.

Now, I wold like to unify the network request interfaces to allow keeping track of the rate limit for APIs and caching but I'm counting on this changes to speed up tests during development.

Those test fail because tests are not respecting rate limits for some APIs now that tests are quicker.

I would like that to be the next issue I work with.