Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEAT]: possibility to override errorRequest #499

Open
1 task done
stromnet opened this issue Dec 20, 2023 · 1 comment
Open
1 task done

[FEAT]: possibility to override errorRequest #499

stromnet opened this issue Dec 20, 2023 · 1 comment
Labels
Status: Up for grabs Issues that are ready to be worked on by anyone Type: Feature New feature or request

Comments

@stromnet
Copy link

Describe the need

doNotRetry only supports checking on status code. This is not enough in some cases.

For example, I have a flow where I create a new repository and then make some additional calls, setting team permissions adding topics etc. Sometimes those follow-up calls fails with 422 and an error like this:

{
  message: 'Validation Failed',
  errors: [
    {
      resource: 'TeamRepository',
      code: 'unprocessable',
      field: 'data',
      message: 'This repository is locked and cannot be modified.'
    }
  ],
  documentation_url: 'https://docs.github.com/rest/teams/teams#add-or-update-team-repository-permissions'
}

While it does not make sense to always retry 422, it would perhaps make sense to do it if code is 422 and message contains this "is locked". In some cases, not all perhaps. Because repos could really be locked too. But in my case I know it wont be.
If I would be able to specify my custom logic, I could tailor it for my needs. Atm I instead opt to clone all code, just to change that logic.

Regarding this particular case, GitHub support have replied that this is expected (https://support.github.com/ticket/personal/0/2465057 if you has access to internal tickets):

It can take time for replication of data, and we lock the repositories during creation and changes to permissions, as you've noted. It really depends on the current load. We recommend retrying with exponential backoff in such situations.

SDK Version

No response

API Version

No response

Relevant log output

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
@stromnet stromnet added Status: Triage This is being looked at and prioritized Type: Feature New feature or request labels Dec 20, 2023
Copy link

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

@nickfloyd nickfloyd moved this from 🆕 Triage to 🔥 Backlog in 🧰 Octokit Active Jan 4, 2024
@kfcampbell kfcampbell added Status: Up for grabs Issues that are ready to be worked on by anyone and removed Status: Triage This is being looked at and prioritized labels Jan 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Up for grabs Issues that are ready to be worked on by anyone Type: Feature New feature or request
Projects
Status: 🔥 Backlog
Development

No branches or pull requests

2 participants