Memory explosion when using include parameter on entries with high branching factor

Hi friends! Some context first, and then a few parts to this question.

We use Contentful to manage (amongst other things) content for a bunch of articles on our site, and one of the fields on the article entries is called related_content, which is a collection of links to other Contentful article entries that are related to the current article.

This gives us a problem if we ever query Contentful for an entry with a call like client.entry('the_article_id', include: 10). The traversal logic ends up crawling the vast branching network of related articles where, often times, different paths in the article graph will repeatedly lead to the same articles, resulting in an exponential explosion in the size of the returned payload.

Question 1 is about the timeout_read parameter in Contentful. I tried the following snippet:

client =
  space: '{my space id}',
  access_token: '{my token}',
  api_url: '',
  timeout_connect: 5,
  timeout_read: 5,
  timeout_write: 5,
client.entry('the article id', include: 10)

but the call to entry ends up taking far longer than 5 seconds and eats up memory on my computer until I’m forced to kill it. Am I misunderstanding how the timeout parameters work? We’d like to be able to at least have a functionality to throw an exception if we ever accidentally perform an expensive query like this, but we instead end up wit memory explosions that require us to manually kill processes to stop the leak.

Question 2 is around whether there’s a way to selectively reduce the include depth for certain fields. In many cases, we’d still like to traverse down to the leaf nodes of a particular entry using an arbitrarily high value like include: 10, but we’d like to be able to specify that we don’t want to traverse for the field related_content. I see there are ways to selectively only include certain fields using the select parameter in the API, but I didn’t see a way to selectively exclude fields. Do you have any suggestions here?