Add a max-timeout option

[ericonr]

Hi! We are using mdbook-linkcheck in CI for https://github.com/void-linux/void-docs, and have faced some issues with it, which can be seen here https://travis-ci.org/github/void-linux/void-docs/builds/713885627 , where it goes over the 10 minute limit for Travis without any output. Locally the same thing is happening, I left it running for at least 15min and didn't get any output.

So, I guess it would be nice to have a max-timeout option or similar to allow for a better UX as well as avoid blocking any CI that's being run. Then mdbook-linkcheck would show the failed links and a decision could be taken to add them to exclude_links.

How would you name such an option? Do you think this is a feature you want?

[Michael-F-Bryan]

Would this max-timeout option be a global timeout (i.e. "the entire linkcheck run should take less than 10 minutes"), or on a per-request basis?

I had a look and it seems like reqwest's client has no timeouts by default. We could use that to timeout individual checks, and wire it into linkcheck::validation::Context.

Otherwise you can wrap the entire validation call (probably around here) with a tokio::time::timeout().

[ericonr]

In our case, I think a global timeout would be the ideal solution, since otherwise we could still hit some edge case and have it stall for over 10 min. I tried looking into the code to add some debug statements, but async is a bit complicated :p

Do you think wrapping the entire validation call in a timeout would work? Would the links that weren't checked still be propagated into error messages?

[Michael-F-Bryan]

You should be able to set RUST_LOG=linkcheck=debug or something and the emitted log statements will be enough to stop travis killing your job.

Do you think wrapping the entire validation call in a timeout would work? Would the links that weren't checked still be propagated into error messages?

I'm guessing the entire linkcheck process would error out and you'd get no error messages (other than the fact linkchecking timed out).

My real question is why linkchecking takes 15+ minutes... That's a long time to be checking links. The most likely causes are:

• your document contains loads of web links (1000+)
• the remote servers take forever to finish sending their responses, or
• there's a bug in linkcheck (or mdbook-linkcheck) which means we deadlock/wait forever

Based on your use of Void Linux book, do the either of the first two sound likely?

[ericonr]

I've counted 334 links, which indeed isn't that much. I would say it's probably the second one, since I haven't been able to reproduce the issue today. I will see about including the debug variable in CI to see if I can catch these issues. Thanks!

[ericonr]

I have a CI log where it locked here: https://travis-ci.org/github/void-linux/void-docs/builds/714715539

Couldn't spot anything of interest and couldn't reproduce locally :/

Got it to hang again https://travis-ci.org/github/void-linux/void-docs/builds/746378935