Have you experienced this in Copilot Workspaces? First day.

[bbarclay]

Has anybody experienced this?

API rate limit exceeded for user ID 374088. If you reach out to GitHub Support for help, please include the request ID 0CC1:1CDD1B:92C437:9AB567:671A7575 and timestamp 2024-10-24 16:27:33 UTC. - https://docs.github.com/rest/overview/rate-limits-for-the-rest-api

[dsyme]

@bbarclay We see these errors in our log for a handful of users, and are trying to work out what scenario they occur in

Could I ask a few details?

• Are you using codespaces/terminal
• Was there anything special or different about your session, or your use of codespaces/terminal, e.g. did you create a lot of files there, or do git operations there?
• Are you using any other OAuth GitHub apps or VSCode extensions which might burn through your GitHub API quota? This is shared across all OAuth GitHub Apps.

[bbarclay]

@bbarclay We see these errors in our log for a handful of users, and are trying to work out what scenario they occur in

Could I ask a few details?

• Are you using codespaces/terminal
  - Yes, a lot. Love it.
• Was there anything special or different about your session, or your use of codespaces/terminal, e.g. did you create a lot of files there, or do git operations there?
  - I did git push for the first time, right before it broke.

• I would consider myself a power user so I'm probably making a ton of requests for files. I had a bug with a modules package, so I've ran through a ton of models. I think I got it figured out this morning, but I might have been running a lot.

• Are you using any other OAuth GitHub apps or VSCode extensions which might burn through your GitHub API quota? This is shared across all OAuth GitHub Apps.

• I have VScode extensions copilot, copilot workspace, etc. I have 5 projects open on my Mac. I wonder if there is some update loop. I also wonder if there is some update loop for all the sessions that are previously opened, but commits not made from those sessions.

Here I wonder, I closed a bunch, but perhaps they are still pulling tokens, everytime a change is made from their main repo.

Even through the session is not open, it's possible that the app under it, is trying to keep up, so when the session is open.

Therefore, the more of these you have open, and the changes you make in the open sessions, causes all of them, and their files to upload logs using the API.

You might try opening 30 of these, then making a bunch of changes on an app, doing a push request, and see if the projects that are not considered open sessions, are making github api requests, for all the files to see if they need to adapat their logs. Or something like that.

It seems like how I might Engineer it.

The reason is, if you open one of those other projects, then go back to a previous one. It's probably a better user experienece if they already know the upstream, or downstream application has changed. Thus in the background you run api requests to all those files (In the background)

1. Check if the closed sessions are still pulling api requests. Essentialy, just a thought.

Ps. I deleted 5 or 6 of those to see if that would bring my rate limit back.

[bbarclay]

I could be off my rocker here, but it's worth sharing.

graph TD
    A[Start push process] --> B{Check for closed or open sessions}
    B --> |Open sessions| C[Notify and check for latest commits]
    B --> |Closed sessions| D[Track sessions and notify them]
    C --> E{Are related session outdated?/closed but not completed}
    D --> E
    E --> |Yes| F[Prompt AI to pull latest changes]
    E --> |No| G[Proceed with push request]
    F --> H[Check for merge conflicts]
    H --> |No conflicts| G
    H --> |Merge conflicts| I[Resolve conflicts]
    I --> G
    G --> J[Complete push]

Loading

Discussion on API Request Overload:
While this setup improves user experience by keeping sessions updated, it could cause problems with API request limits. GitHub APIs (or any similar service) often have rate limits, meaning each request to notify or update a session counts against that quota.

Potential Issues:
Closed Sessions Overload: If you don’t manage session lifecycle properly, every time a push is made, the system might attempt to notify closed sessions. If there are many such sessions, it could lead to an explosion of API requests. For example, if 100 closed sessions all request updates simultaneously, it could easily blow through your request limit.

Unnecessary Requests: These requests would not add much value because closed or outdated sessions may not be active, leading to wasted API calls. In cases where multiple pushes happen in a short time, this could compound the problem.

Possible Fixes:

Session Timeouts: Implementing session timeouts or garbage collection that clears closed or outdated sessions after a certain period.
Throttling: Limit how frequently notifications and checks are made for closed sessions to avoid spamming the API.
Batch Requests: Instead of individual requests for each session, batch requests for multiple session updates to reduce the API call volume.

[bbarclay]

Sorry one more thing. I unzipped in the CLI two repos. I uploaded them as zip files. then told your application to unzip them.

I wonder if the application made api requests to pull back and check each one of the files after they were unzipped. I noticed a ton of untracked changes.

[bbarclay]

It happened again, but I had accidentally created two new repos. I wonder if it has something to do, with it creating a bunch of files. All those files each sending an api request.

[dsyme]

@bbarclay What is the name of your repo? See this:

For incoming URLs, some repositories are treated as templates by default:

Any GitHub template repository
Any repository in an organization containing templates, upper or lower case, with dash at start or end
Any repository with -template, -scaffold, -starter or -boilerplate in its name, upper or lower case, with dash at start or end

[genidma]

I could be off my rocker here, but it's worth sharing.

graph TD
    A[Start push process] --> B{Check for closed or open sessions}
    B --> |Open sessions| C[Notify and check for latest commits]
    B --> |Closed sessions| D[Track sessions and notify them]
    C --> E{Are related session outdated?/closed but not completed}
    D --> E
    E --> |Yes| F[Prompt AI to pull latest changes]
    E --> |No| G[Proceed with push request]
    F --> H[Check for merge conflicts]
    H --> |No conflicts| G
    H --> |Merge conflicts| I[Resolve conflicts]
    I --> G
    G --> J[Complete push]

Loading

Discussion on API Request Overload: While this setup improves user experience by keeping sessions updated, it could cause problems with API request limits. GitHub APIs (or any similar service) often have rate limits, meaning each request to notify or update a session counts against that quota.

Potential Issues: Closed Sessions Overload: If you don’t manage session lifecycle properly, every time a push is made, the system might attempt to notify closed sessions. If there are many such sessions, it could lead to an explosion of API requests. For example, if 100 closed sessions all request updates simultaneously, it could easily blow through your request limit.

Unnecessary Requests: These requests would not add much value because closed or outdated sessions may not be active, leading to wasted API calls. In cases where multiple pushes happen in a short time, this could compound the problem.

Possible Fixes:

Session Timeouts: Implementing session timeouts or garbage collection that clears closed or outdated sessions after a certain period. Throttling: Limit how frequently notifications and checks are made for closed sessions to avoid spamming the API. Batch Requests: Instead of individual requests for each session, batch requests for multiple session updates to reduce the API call volume.

@bbarclay Off-topic, I am curious how you made the flowchart and also embedded it in Github here? Thx