Batch query

Batch query

Usage

.batch_query(
  urls,
  batch_size = 5,
  msg = "Batch Query",
  delay = 0.5,
  accept = "application/json",
  req_func = function(req) {
     req
 },
  throttle_capacity = NULL,
  throttle_fill_time_s = 1,
  timeout_s = 60
)

Arguments

urls

A vector of URLs

batch_size

Size of each batch

msg

Message to show in progress bar - set to NULL to omit progressbar

delay

Courtesy delay between batches (in seconds)

accept

The header type to accept

throttle_capacity

requests per throttle_fill_time_s to allow, or NULL (default) for no throttling. Only set this for a host known to rate-limit (e.g. CrossRef); for others, req_retry's backoff already handles the rare 429 and a proactive throttle would just slow things down for no benefit.

throttle_fill_time_s

time window (seconds) throttle_capacity applies to. Ignored when throttle_capacity is NULL.

timeout_s

per-request timeout (seconds). req_perform_sequential() is a single blocking call with no timeout of its own, so a connection the remote accepts but then stalls on (no error, no close, just silence) blocks forever – confirmed live 2026-09-07 (Cooper corpus rerun) via zenodo_info()'s call here, hanging on a Zenodo record lookup for over an hour with near-zero CPU and one open connection. Unlike a file download, a metadata/listing response has no meaningful "expected size" to scale against (see download_repo_files()'s size-scaled timeout for that case), so this is a flat default generous enough for a slow-but-real API response while still bounding a truly stalled connection.

Value

a list of responses