Adding an appendix on real-world all-VO queries to the registry docs.

[msdemlei]

This is an attempt to address
#289 (comment)

[codecov]

Codecov Report

Merging #342 (8871833) into main (197cd38) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #342   +/-   ##
=======================================
  Coverage   78.28%   78.28%           
=======================================
  Files          46       46           
  Lines        5493     5493           
=======================================
  Hits         4300     4300           
  Misses       1193     1193           

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[bsipocz]

Thank you @msdemlei, this totally addresses my concern raised in #289.

[andamian]

Yes, this looks good although it's just for interactive sessions. Are there any default timeouts in search for services that do not respond for some reasons or a mechanism to allow non-interactive sessions to avoid hangs?

[msdemlei]

On Thu, Jun 09, 2022 at 09:38:13AM -0700, Adrian wrote: Yes, this looks good although it's just for interactive sessions. Are there any default timeouts in `search` for services that do not respond for some reasons or a mechanism to allow non-interactive sessions to avoid hangs?

Services have service-dependent timeouts; mine, for instance, times out in ~10 seconds on sync, but other services are a lot more generous there (I'm stingy because I want to keep the RegTAP endpoint responsive). That doesn't necessarily help, though, because when run_sync hangs for a long time, it's rather typically because the TAP service is actually down and there is a reverse proxy waiting for a response until *it* times out (which can be a long time). Timing out on our end by default would, I think, not be wise either. Since it's totally reasonable that sync queries take, say, two minutes (on services more generous than mine), we definitely shouldn't make the timeout shorter than that. And a timeout longer than 100 seconds, I'd say, doesn't help in normal cases but hurts in many less normal situations. Having said that, all-VO queries might profit from giving the user a simple way of *supplying* a timeout. A quick peek into dal.query hasn't brought up an obvious way to supply run_sync with a timeout. Perhaps we should add one? And while we're doing that for run_sync, perhaps offer optional timeouts for the S*AP queries, too?