feat: properly handle task limits

[jordan-ae]

Resolves #28

This PR updates the conditions for handling task limits

[0x4007]

@zugdev perhaps you can help test and review this since you seem the most affected

[zugdev]

@zugdev perhaps you can help test and review this since you seem the most affected

sure! @jordan-ae do you have a bot running this fix?

[jordan-ae]

sure! @jordan-ae do you have a bot running this fix?

I'll add a QA link to the issue preview soon. But to test this locally you'll have to set the ubiquity-os-kernel up, clone and setup the command-start-stop repo. Then you can test this locally

[ubiquity-os-beta]

@jordan-ae, this task has been idle for a while. Please provide an update.

[jordan-ae]

@0x4007 I've added a QA. Looks like everyone is really busy but the changes here are really minimal should be pretty straight forward to review hopefully

[0x4007]

@whilefoo @gentlementlegen @zugdev can you test this

[zugdev]

With your QA you should've demonstrated that if a PR is waiting for review the active issue count of the user is aliviated. That's so he can start more issues while his PRs are pending review. I'll try to QA it myself tomorrow or the day after that.

[gentlementlegen]

What should also be tested is the +1 task available after the threshold for reviews is due.

[jordan-ae]

@zugdev & @gentlementlegen not sure if I linked it poorly but that's what the QA demonstrates. The user's initial task limit is 2. He self assigns the two task and can't asign himself to task 3 until an approved pr is opened against one of his current task. Once a pr is opened and has an approval +1 task is added to his task limit.

[gentlementlegen]

I tested with your changes and here is what I get:

• I am using user @ubiquity-ubiquibot
• It has one Issue assigned: Issue Meniole/command-start-stop#39
• This issue has a PR assigned: PR Meniole/command-start-stop#42
• The task limit for the contributors is set to 1
• the review delay is set to 1 minute
• it tries to start another task: Issue Meniole/command-start-stop#43

Finally the assigment gets denied with the following values

        ⚠ You have reached your max task limit
        ⚠ {
            "assignedIssues": 1,
            "openedPullRequests": 0,
            "limit": 1,
            "caller": "handleTaskLimitChecks"
          }

It seems the openedPullRequest is wrong.

[ubiquity-os-beta]

@jordan-ae, this task has been idle for a while. Please provide an update.

[jordan-ae]

@gentlementlegen I've been facing this error on /start when testing. It's trying to check pull request that do not exist I've cleared all existing changes and still get the same error. Do you have any idea what might be causing the error?

[gentlementlegen]

@jordan-ae never happened to me before. Have you changed your code for testing and forgot to revert it? It should be fetching the pull-requests from GitHub API so there cannot be items that do not exist there.

[jordan-ae]

Thought so too. But I've reverted all the changes, same Issue. So I recloned the repo, same issue still.

[gentlementlegen]

Does this reference a private repository? Otherwise there could be a bug then you should investigate why this repository gets listed if it doesn't exist.

[whilefoo]

I don't think fully implements the specification in which I stated that after the review changes are resolved or the reviewer was requested again, it should be counted as completed

[jordan-ae]

I don't think fully implements the specification in which I stated that after the review changes are resolved or the reviewer was requested again, it should be counted as completed

Missed that when reading the spec. Will add Asap

[whilefoo]

if I have 1 issue and 1 PR with requested changes, it will count as 2 here but it should only count 1

[github-actions]

Unused types (1)

Filename	types
src/types/payload.ts	Review

[jordan-ae]

Feature works now but I'm having a hard time writing a handler for this function to make the test pass

[gentlementlegen]

The first issue in the tests is

HttpError: API rate limit exceeded for 52.238.24.178. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.) - https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting

make sure a token is provided during the tests for these.

[ubiquity-os-beta]

@jordan-ae, this task has been idle for a while. Please provide an update.