Updating Priority Levels Removes Pricing From Many Issues

[0x4007]

This is bad because I have to go back in and manually re-add all the pricing.

Example:

• ubiquity-os-marketplace/.ubiquity-os@3635c01
• causes Add allowed roles to requiredLabelsToStart command-start-stop#100 (comment)

This isn't the first time this happened either, with other "normal" priority levels.

After a quick look at our https://github.com/orgs/ubiquity/projects/27 I noticed it only seems to do it inside of the @ubiquity-os-marketplace organization. The other two organizations were not affected, even after doing the same config changes.

Due to exceeded rate limits, it is possible that this failed halfway through the process.

As of this moment I won't fix the price labels but in case they are left as is, these can be useful to review for reference for not being affected:

https://devpool.directory/ubiquity-os-marketplace

https://devpool.directory/ubiquity-os-marketplace?proposal=true

[ubiquity-os-beta]

Note

The following contributors may be suitable for this task:

gentlementlegen

2% Match ubiquity-os-marketplace/daemon-pricing#47

0x4007

1% Match ubiquity/work.ubq.fi#125

rndquu

1% Match ubiquity/audit.ubq.fi#16

[gentlementlegen]

I don't know if it is related but I noticed that this plugin has a very hard time with quick and batch changes of labels, even more when it is not allowed, e.g. I am not allowed to set a price but at the same time I set a price and remove a time. Since both are un-allowed, the bot doesn't know how to revert the changes properly. Second, the other problem is that changing a label triggers two events: "unlabel" and "label". There probably could be a race-condition with the two events.

[0x4007]

the bot doesn't know how to revert the changes properly

We should definitely be leveraging the timeline to understand how to correctly revert

triggers two events: "unlabel" and "label".

Good observation I suppose we should refactor our logic here to take this into consideration

[Sadaf-A]

/start

[ubiquity-os-beta]

! You do not have the adequate role to start this task (your role is: member). Allowed roles are: collaborator, admin.

[gentlementlegen]

@0x4007 I also noticed this has a flaw: if you update the base rate of the organization repository, I think that all the price tags will be updated with that new multiplier. But if a repo overrides this value then it will have the wrong multiplier applied to that repository.

[0x4007]

Seems like a complex fix.

Maybe it's more efficient to check the base rate during another event, perhaps something more localized like if a comment is posted on an issue or something, and to only fix that issues pricing.

Worst case scenario somebody /start and it changes the price right after they start. Annoying but at least they didn't actually do any work yet?

[gentlementlegen]

I think it is similar to the problem we have with daemon-disqualifier which uses the configuration of the repo it was triggered on, but actually updates all the repos using that same configuration. I'll try to find a workaround for this.

[0x4007]

Sure, but my point is that my proposed approach would solve for that as well. I think it might be a better strategy given how simple it would be to implement.

I'm also keen to remove base rate update because it is the sole reason why daemon-pricing responds so slow to set a price.