Edgecase where no flat field can be selected at the maximum depth

[Alan-Cha]

An error is thrown if a query hits the defined maxDepth, but there are only fields with children to choose from. Choosing such a field but then not choosing a sub-field for it (due to the maxDepth constraint) would result in an invalid query and thus causes this library to throw an error.

[Alan-Cha]

#9 Will address this issue by adding the meta field __typefield however I have concerns about this will be a confusing change to our users. Normally __typefield will be added as a part of union and interface use cases however, in this case, we will be adding the meta field wherever necessary.

I believe that this is still a good change overall but I think in future, we should look into properly solving the issue by recursively ensuring that there are fields that can be added without violating the maxDepth rule.

[alexkrolick]

Would it be possible to add an option to soft-enforce the maxDepth rule for this case? Otherwise it's difficult to run random queries as an automated fuzz testing suite, because the tests hard fail randomly.

[Alan-Cha]

@alexkrolick I'm currently working on a number of other projects so it is difficult for me to look at this right now.

We have experienced problems due to this issue and in the past, one of our workarounds was to simply create a helper function that wraps the query generator in a try/catch block and a while loop. I know this is far from ideal but until I can find some time to look into this issue, I will have to rely on external contributions to help resolve this issue.