Troubleshoot - MCP server? at capacity of timeseries-molecular repo

[sr320]

It appears the timeseries repo has hit some type of limit / error when using GitHub issues and assigning co-pilot to address issue as pull request.

Can you recreate by assigning simple issue to co-pilot using web interface and determine solution(s) for error that should arise?

[kubu4]

I'll give it a rip, however, I suspect it's related to a Cloudflare outage which has broken a LOT of sites, including OpenAI (i.e. ChatGPT).

[sr320]

Appears to be specific to this repo…

…

On Tue, Nov 18, 2025 at 7:55 AM kubu4 ***@***.***> wrote: *kubu4* left a comment (RobertsLab/resources#2376) <https://urldefense.com/v3/__https://github.com/RobertsLab/resources/issues/2376*issuecomment-3548340085__;Iw!!K-Hz7m0Vt54!n80q_Wqshug3bj9FR9dtdC9sx4B383CKxOBeLYIqhiHVFdoEERVokdr4NU6PNV85WoAsdaYNeZAC2d8vE3F8CuA$> I'll give it a rip, however, I suspect it's related to a Cloudflare outage which has broken a LOT of sites, including OpenAI (i.e. ChatGPT). — Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/RobertsLab/resources/issues/2376*issuecomment-3548340085__;Iw!!K-Hz7m0Vt54!n80q_Wqshug3bj9FR9dtdC9sx4B383CKxOBeLYIqhiHVFdoEERVokdr4NU6PNV85WoAsdaYNeZAC2d8vE3F8CuA$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABB4PN47Y3ZP4D5TRX6QXZL35M6N3AVCNFSM6AAAAACMOYNXYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBYGM2DAMBYGU__;!!K-Hz7m0Vt54!n80q_Wqshug3bj9FR9dtdC9sx4B383CKxOBeLYIqhiHVFdoEERVokdr4NU6PNV85WoAsdaYNeZAC2d8vskNizvI$> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kubu4]

Diving into this, it appears that the standard GitHub action "runners" (these are the virtual machines that spin up behind the scenes when an action is utilized - e.g. GitHub Copilot) are maxed out at 14GB.

The repo's full size is currently 21GB.

Why're we're hitting the wall now? I don't know. There is probably more nuance involved in how the repo is utilized by the runners when they're started up that I don't understand.

Options:

1. Delete stuff from the repo. There are likely various "cache" directories that people have used when running R code that might be able to be deleted with minimal impact to the repo's functionality.

2. Delete a large git repo pack that is consuming 4.65GB of space. This is likely due to a commit at some point which included large files. However, once the commit exists, those files still exist in the repo history. If we were to delete these, this would require usage of a push --force, which will overwrite the git history and screw up everyone's local copy of the repo. We would definitely need/want to coordinate this with everyone else using the repo before we did it.

Of course, deleting this one repo pack won't drop us below the 14GB runner space requirement, so not sure if this is actually helpful, considering how much of a headache it will be to coordinate the deletion process with everyone.

[sr320]

I presume it’s based on volume of co-pilot requests then - Is there a way to delete the cache as we have output of actions? Or use our own runners?

…

On Tue, Nov 18, 2025 at 10:11 AM kubu4 ***@***.***> wrote: *kubu4* left a comment (RobertsLab/resources#2376) <https://urldefense.com/v3/__https://github.com/RobertsLab/resources/issues/2376*issuecomment-3548950994__;Iw!!K-Hz7m0Vt54!mrhJupM5IwIWJWl0ghQ4jJCKfm6fo4ZBVlGj3mNmane4g21hHIXSINimYJZxMW4Je6Is7IpjZY3Fk169eVxBrIo$> Diving into this, it appears that the standard GitHub action "runners" (these are the virtual machines that spin up behind the scenes when an action is utilized - e.g. GitHub Copilot) are maxed out at 14GB. The repo's full size is currently 21GB. Why're we're hitting the wall now? I don't know. There is probably more nuance involved in how the repo is utilized by the runners when they're started up that I don't understand. Options: 1. Delete stuff from the repo. There are likely various "cache" directories that people have used when running R code that might be able to be deleted with minimal impact to the repo's functionality. 2. Delete a large git repo pack that is consuming 4.65GB of space. This is likely due to a commit at some point which included large files. However, once the commit exists, those files still exist in the repo history. If we were to delete these, this would require usage of a push --force, which will overwrite the git history and screw up everyone's local copy of the repo. We would definitely need/want to coordinate this with everyone else using the repo before we did it. Of course, deleting this one repo pack won't drop us below the 14GB runner space requirement, so not sure if this is actually helpful, considering how much of a headache it will be to coordinate the deletion process with everyone. — Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/RobertsLab/resources/issues/2376*issuecomment-3548950994__;Iw!!K-Hz7m0Vt54!mrhJupM5IwIWJWl0ghQ4jJCKfm6fo4ZBVlGj3mNmane4g21hHIXSINimYJZxMW4Je6Is7IpjZY3Fk169eVxBrIo$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABB4PN4VQB2M43AWRWW7GY335NOOBAVCNFSM6AAAAACMOYNXYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBYHE2TAOJZGQ__;!!K-Hz7m0Vt54!mrhJupM5IwIWJWl0ghQ4jJCKfm6fo4ZBVlGj3mNmane4g21hHIXSINimYJZxMW4Je6Is7IpjZY3Fk169HQd6bLI$> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kubu4]

Actions cache is empty, so not an issue related to that.

Additionally, the artifacts generated by copilot actions are each only ~1.5kB. There are only 46 copilot actions in the history (they get deleted after 90 days), so those are not consuming space, either.

It's related to the fact that when a copilot action runs, it clones the repo. So, the repo size is too large to work on the runners.

[kubu4]

Yes, we can setup our own runners, but I have not explored that.