Super-productivity: Gitlab: Is not properly configured => implement bulk update check

[oshotton]

Looking at the console errors I believe this to be an issue with hitting the GitLab API too frequently. HTTP Status Code 429 Too Many Requests.

On a side note, I think the error message needs updating for this type of error too. I would say that GitLab is configured correctly as I can see GitLab issues. This error is more related to api rate limiting.

Your Environment

• Version used: 5.9.9 Microsoft Store
• Operating System and version: W10 2004 (build 19041.508)

Expected Behavior

Update the GitLab issues without errors

Current Behavior

Pop-up repeatedly appears at bottom of app saying Gitlab: Is not properly configured.

Steps to Reproduce (for bugs)

1. Setup 3 projects with GitLab integration
2. Go to each project and add some tasks (from GitLab and just in super productivity)
3. Keep flipping between projects adding tasks until the Gitlab: Is not properly configured error repeatedly appears

Console Output

GLOBAL_ERROR_HANDLER Error: Uncaught (in promise): Object: {"HANDLED_ERROR_PROP":"Gitlab: Http failure response for https://gitlab.com/api/v4/projects/organization%2Fgroup%2Fproject/issues?order_by=updated_at&per_page=100&page=1: 429 OK"}
    at S (polyfills.aebe8ecc43d658291381.js:1)
    at polyfills.aebe8ecc43d658291381.js:1
    at s (main.5a62f0f816872b3b2a47.js:1)
    at t.invoke (polyfills.aebe8ecc43d658291381.js:1)
    at Object.onInvoke (main.5a62f0f816872b3b2a47.js:1)
    at t.invoke (polyfills.aebe8ecc43d658291381.js:1)
    at e.run (polyfills.aebe8ecc43d658291381.js:1)
    at polyfills.aebe8ecc43d658291381.js:1
    at t.invokeTask (polyfills.aebe8ecc43d658291381.js:1)
    at Object.onInvokeTask (main.5a62f0f816872b3b2a47.js:1)
t.handleError @ main.5a62f0f816872b3b2a47.js:1

Error Log (Desktop only)

Can't do this, the %USERPROFILE%\AppData\Roaming\superProductivity folder does not exist...

[johannesjo]

Hi! Thanks for opening this up. This might happen if you use the issue search very often. In this case, you might want to disable the feature. You can use the network tab of the dev tools (Ctrl+Shift+i) to check how many requests are actually going on. Not sure if this is up to date, but if you type a ten letter word with every keystroke being slower than 300ms within a 10 second time frame than you might hit this.

I couldn't find any more information about the 600 (is it for a day, an hour or a month??), but this might also be the cause.

Not sure what the best way to approach this is. Maybe I should increase the debounce delay, so the app waits longer before actually sending out a request. This might feel a little slow to some users though.

[johannesjo]

Sorry, I didn't read your description well enough. How many open issues do you have imported to these lists? There is a request made for every single one of them to check for updates. If you have many of these imported the limit might be reached quickly.

Maybe a good improvement would be to use a batch request if possible. I've to check this.

[oshotton]

Hi, thanks for the quick reply!

I was using the search feature quite a bit at the time as was adding issues to various projects.

I just restarted the program, opened the dev tools and waited for the Gitlab: Polling Changes for issues to appear. The Network tab listed 404 requests and no errors in the Console tab. I waited for the Gitlab: Polling Changes for issues again. I did not do any searching in between. The Network tab had 5505 / 41847 requests with 9786 errors in the Console tab.

I currently have 3 projects and 207 issues synced. This doesn't seem like a crazy amount. I do plan on adding more though. A batch request seems sensible and maybe if you receive a 429 status code just have one error show and don't try to update for a few minutes.

I also tried to look for what the gitlab.com API rate limit settings where and couldn't find anything concrete... 600 might be true if no errors happened the first time with just 404 requests.

[MostafaAmin07]

Hi, There is a rate limit of 600 requests per minute (you can find more about it in here https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41308) and it can be hit very easily with projects that has more than 100 issues especially if as you stated you were moving from one project to another as the refresh function is called for every single issue firing 2 requests one for the issue itself and one for the comments.

However ~42K requests is crazy and I have no idea what can cause all of that so I will try to recreate a similar scenario with a repo that has a lot of issues.

I will take a look at this and hopefully it will be fixed in the next couple of days.

[johannesjo]

Hey @MostafaAmin07 welcome back! :)