/stop can start again

[0x4007]

example

ubiquity/ts-template#61 (comment)

Calling stop should not penalize. If they called stop they should be able to reassign in the future becauss its not a disqualification.

[ishowvel]

the specification seems pretty straight forward

[ishowvel]

/start

[ubiquity-os-beta]

Deadline	Mon, Oct 28, 8:08 AM UTC
Beneficiary	0x340D8d2bd82dEb4f485623453c9F6ad307e6B027

Tip

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the task.

[ishowvel]

i have noticed that only 1 plugin works in the kernel at the time, my pricing plugin doesnt work when i add this start stop plugin to the .ubiquity-os config, the kernel only forwards the payload to one plugin for some reason

[ishowvel]

this may already be implemented

[ishowvel]

/stop

[ishowvel]

/start

[ubiquity-os-beta]

! ishowvel you were previously unassigned from this task. You cannot be reassigned.

[ishowvel]

@gentlementlegen might you know why the kernel is only forwarding payload to the first plugin found in any repo containing the ubiquity-os config like found here

[wrangler:inf] POST /events 200 OK (1397ms)
Creating empty kv KvNamespace {}
Event issue_comment received (id: bae1fd80-9536-11ef-8375-aa28c5354825)
Skipping plugin chain Assistive pricing because command does not match. {
  allow: {
    'ubiquity:example': '/allow @user1 label',
    description: 'Allows the user to modify the given label.'
  }
}
[wrangler:inf] POST /events 200 OK (1009ms)

[ishowvel]

the kernel doesnt even know if these plugins exist

[0x4007]

My best guess is that you have a formatting problem in your yml config. Sometimes it's difficult to get the indentations perfectly.

[gentlementlegen]

It is trying to forward it but what it received is not a valid command like /label. Plugins react only to certain events / inputs.

[ishowvel]

Shouldn't it receive the valid commands for this plugin ie /start, /stop

[gentlementlegen]

In the configuration file you gave, you chained plugins so it won't. You need to change it to something like

plugins:
  - uses:
    - plugin: http://127.0.0.1:4000
      with:
        labels:
          time:
            - "Time: <15 Minutes"
            - "Time: <1 Hour"
            - "Time: <2 Hours"
            - "Time: <4 Hours"
            - "Time: <1 Day"
            - "Time: <1 Week"
            - "Time: <2 Weeks"
            - "Time: <1 Month"
          priority:
            - "Priority: 1 (Normal)"
            - "Priority: 2 (Medium)"
            - "Priority: 3 (High)"
            - "Priority: 4 (Urgent)"
            - "Priority: 5 (Emergency)"
        basePriceMultiplier: 2
        publicAccessControl:
          setLabel: true
          fundExternalClosedIssue: false
  -  uses:
    - plugin: ishowvel/daemon-disqualifier:compute.yml@testing
      with:
        disqualification: "2 minutes"
        warning: "1 minutes"
        watch:
          optOut:
            - "repoName"
            - "repoName2"
        eventWhitelist:
          - "review_requested"
          - "ready_for_review"
          - "commented"
          - "committed"
  - uses:
    - plugin: http://localhost:4001 # or the URL where the plugin is hosted
      name: start-stop
      id: start-stop-command
      with:
        reviewDelayTolerance: "3 Days"
        taskStaleTimeoutDuration: "30 Days"
        maxConcurrentTasks: # Default concurrent task limits per role.
          member: 5
          contributor: 3
        startRequiresWallet: true # default is true
        emptyWalletText: "Please set your wallet address with the /wallet command first and try again."
        rolesWithReviewAuthority: ["MEMBER", "OWNER"]
    

so every plugin is called individually.

[ishowvel]

@0x4007 can i be assigned to this

[ubiquity-os-beta]

@ishowvel the deadline is at Thu, Oct 31, 7:54 PM UTC

[ubiquity-os-beta]

A new workroom has been created for this task. Join chat

[ishowvel]

@0x4007 i cant seem to recreate the issue

[ishowvel]

the problem for me was i was using the github app id as the BOT_USER_ID but instead i should have used

[0x4007]

Show me the conversation/QA on GitHub so I have context on your problem

[ishowvel]

ishowvel-org/.ubiquity-os#4
After a certain point i switched the BOT_USER_ID from the GitHub app Id to the GitHub app user id

[0x4007]

It looks like it works. @gentlementlegen rfc

[gentlementlegen]

It should not, otherwise it means that users can also assign themselves again after disqualification.

[ishowvel]

No I mean that if no code was changed, it should not allow re-assign with the current implementation.

if thats the case i dont see how this issue should even be worked on, i think this should be closed as not planned

[ishowvel]

/stop

[ariesgun]

/start

[ariesgun]

Could not reproduce the issue in the local environment.
One possible reason it failed is BOT_USER_ID's misconfigured??

const botUnassigned = unassignedEvents.filter((event) => event.actorId === BOT_USER_ID);

[gentlementlegen]

The BOT_USER_ID should match the id of the app your installed in your org @Keyrxng rfc

This is still relevant since this line is in the codebase:

command-start-stop/src/handlers/shared/start.ts

Line 181 in 00c8675

if (await hasUserBeenUnassigned(context, username)) {

[Keyrxng]

BOT_USER_ID === payload.user.type === "BOT" && payload.user.login === "UbiquityOS"

It is the literal ID of the User entity which belongs to the app. Not the APP_ID which is the app's identifier.

rest.user.getByUsername("ubiquity-os-beta").data.id

[ariesgun]

/stop

[ariesgun]

/start

[ubiquity-os-beta]

! ariesgun you were previously unassigned from this task. You cannot be reassigned.

[ariesgun]

Cannot assign the issue to me anymore.

BOT_USER_ID === payload.user.type === "BOT" && payload.user.login === "UbiquityOS"

Not sure if this is what is used in the code, but shouldn't it be

rest.user.getByUsername("ubiquity-os-beta[bot]").data.id

[Keyrxng]

Cannot assign the issue to me anymore.

BOT_USER_ID === payload.user.type === "BOT" && payload.user.login === "UbiquityOS"

Not sure if this is what is used in the code, but shouldn't it be

rest.user.getByUsername("ubiquity-os-beta[bot]").data.id

Yeah sorry you are correct it's probably better to use -beta[bot] than just ubiquity-os[bot] but you get the idea it's user.id of the bot entity

[ariesgun]

Cannot assign the issue to me anymore.

BOT_USER_ID === payload.user.type === "BOT" && payload.user.login === "UbiquityOS"

Not sure if this is what is used in the code, but shouldn't it be

rest.user.getByUsername("ubiquity-os-beta[bot]").data.id

Yeah sorry you are correct it's probably better to use -beta[bot] than just ubiquity-os[bot] but you get the idea it's user.id of the bot entity

I see.. so for this issue, is it possible to verify if the BOT_USER_ID in dev.vars is set properly or not?
If I look inside function,

command-start-stop/src/handlers/shared/start.ts

Line 181 in 00c8675

if (await hasUserBeenUnassigned(context, username)) {

,

the most probable root cause is the event.actorId !== BOT_USER_ID

[Keyrxng]

The cause is likely because we have two bots and so we have two BOT_USER_IDs to compare. Perhaps it makes sense to add both bot ids and check the actor.id against both?

That is just an assumption obviously but to answer the question: TypeBox verifies that the env vars are defined. Whether they reflect our actual bot is another question, we opt'd for the ID over the username a while back although if there is no other clean solution it'll have to do.

[ariesgun]

Or just check for [bot] in the actorname?

[Keyrxng]

Or just check for [bot] for the actorname?

That's a quick fix I guess yes.

The original intention behind specifying it's our bot was so that in a partner org where they may have lots of little bots installed that perform actions on tasks and PRs this avoids any interference with our logic.

[gentlementlegen]

I think it is safe to assume that a bot un-assign action is from our bot, and would cover both cases.

[ariesgun]

If it is agreed to do it this way, (check name for [bot] I can make the changes quickly .
Can you assign this task to me again?

[Keyrxng]

@ariesgun Sounds to me like it was implied so yeah go ahead with that solution. I can't assign you but you can link the PR and you'll be assigned when someone else sees this

[gentlementlegen]

@ariesgun i think you should check for the user type to be a bot instead.

[ubiquity-os-beta]

! This task does not reflect a business priority at the moment. You may start tasks with one of the following labels: Priority: 3 (High), Priority: 4 (Urgent), Priority: 5 (Emergency)

[ariesgun]

@0x4007 , is it possible to start this task?

[ubiquity-os-beta]

! This task does not reflect a business priority at the moment. You may start tasks with one of the following labels: Priority: 3 (High), Priority: 4 (Urgent), Priority: 5 (Emergency)