I recently ran into some trouble when simply re-building a container that I've been using for some time. I don't have the original, full error message at hand anymore, but it was something along the lines of Cannot index string with string "assets". It was pretty obvious from the full log that this issue occurred as part of the installation of the docker-in-docker feature.
One important thing to note was that the issue presented itself intermittently: the installation finally succeeded after several rebuilds.
A little digging around revealed that this error originated from the bit of the docker-in-docker install script that tries to fetch the latest version of docker-compose. More specifically, this statement was failing to find the "assets" field on any elements returned from https://api.github.com/repos/docker/compose/releases.
I tried calling the URL myself, and I got back valid JSON with plenty of objects with valid "assets" fields, so I was puzzled at the time as to what was causing this problem. But, as mentioned before, the issue was intermittent, and eventually went away on its own, so I didn't think much of it afterwards.
However, I happened to have the tab to https://api.github.com/repos/docker/compose/releases still open in Chrome, and I just noticed today that the same API call which displayed a JSON payload with a bunch of elements is now showing the following:
{"message":"API rate limit exceeded for 13.110.54.11. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting"}I assume that this was the source of the issue I was facing before. If that's the case, I'm probably not the only one out there facing this problem: anyone who happens to be installing docker-in-docker, or any other features which employ the same logic, would run into the same problem whenever the API call is being throttled.
Since the root cause of this problem (API throttling) is ultimately out of the control of the devcontainers project itself, I don't necessarily expect this to be a simple fix. But at the very least, I would recommend making sure that the results of any calls made to GitHub APIs are validated, and a the user provided with a clear user message if such a situation arises.
I recently ran into some trouble when simply re-building a container that I've been using for some time. I don't have the original, full error message at hand anymore, but it was something along the lines of
Cannot index string with string "assets". It was pretty obvious from the full log that this issue occurred as part of the installation of the docker-in-docker feature.One important thing to note was that the issue presented itself intermittently: the installation finally succeeded after several rebuilds.
A little digging around revealed that this error originated from the bit of the docker-in-docker install script that tries to fetch the latest version of docker-compose. More specifically, this statement was failing to find the "assets" field on any elements returned from https://api.github.com/repos/docker/compose/releases.
I tried calling the URL myself, and I got back valid JSON with plenty of objects with valid "assets" fields, so I was puzzled at the time as to what was causing this problem. But, as mentioned before, the issue was intermittent, and eventually went away on its own, so I didn't think much of it afterwards.
However, I happened to have the tab to https://api.github.com/repos/docker/compose/releases still open in Chrome, and I just noticed today that the same API call which displayed a JSON payload with a bunch of elements is now showing the following:
{"message":"API rate limit exceeded for 13.110.54.11. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting"}I assume that this was the source of the issue I was facing before. If that's the case, I'm probably not the only one out there facing this problem: anyone who happens to be installing docker-in-docker, or any other features which employ the same logic, would run into the same problem whenever the API call is being throttled.
Since the root cause of this problem (API throttling) is ultimately out of the control of the devcontainers project itself, I don't necessarily expect this to be a simple fix. But at the very least, I would recommend making sure that the results of any calls made to GitHub APIs are validated, and a the user provided with a clear user message if such a situation arises.