I've been experimenting with the [GenomicDataCommons][1] package to handle query work against the GDC API.  For some reason there is an issue with timeouts for requests of a certain length.  There doesn't seem to be a direct way around this using the piped syntax.  Anyone else have luck with this? 

There is a results(size = n) method, its syntax seems to allow only the first n records to be accessed.

Here is an example query (should return 400-500 records):

    proj <- 'TCGA-COAD'
    case_data <- cases() %>%
      GenomicDataCommons::filter(~ project.project_id == proj) %>%
      GenomicDataCommons::expand('diagnoses') %>%
      results_all() %>%
      as_tibble()

 Gives, after a few moments:

    Error in is.response(x) : Internal Server Error (HTTP 500).


  [1]: https://bioconductor.org/packages/release/bioc/html/GenomicDataCommons.html
I should clean up the documentation, but `results_all()` is a convenience wrapper that is not too smart in that it simply tries to return all results in one trip to the server. This can fail for multiple reasons related to the size of result sets. The better approach (and the only one in the case of large results sets) is to page through the results:


    proj <- 'TCGA-COAD'
    query = cases() %>%
        GenomicDataCommons::filter(~ project.project_id == proj) %>%
        GenomicDataCommons::expand('diagnoses')
    count = query %>% count()
    size = 50
    reslist = lapply(seq(1,count, size), function(start) {
        query %>% 
            results(size=size, from = start) %>%
            as_tibble()
    })
    case_data = bind_rows(reslist)

Unfortunately, the `size` parameter really requires trial-and-error to find the largest "working" setting since the results can vary quite significantly in volume. Instead, I usually just choose a smallish number like 50 or so and wait a few extra seconds. These calls can, in theory, be parallelized using something like BiocParallel to get really fancy (and introduce complexity). 