Use BOT_USER_ID over APP_ID

[Keyrxng]

I'm not sure that this is related to the previously linked issue so I'm removing the reference

• APP_ID cannot be used to ID the bot
• remove two comment postings
• pass decodedEnv

[0x4007]

What exactly is "bot user id"

[Keyrxng]

What exactly is "bot user id"

It's literally the user.id of the bot entity. The id you'd get in the response if you used the fetchByUsername endpoint with the bot username

[gentlementlegen]

I am fine with the code changes although I am not sure to understand why it is needed? We'll have to add this variable to the environment once merged.

[Keyrxng]

I am fine with the code changes although I am not sure to understand why it is needed? We'll have to add this variable to the environment once merged.

It's required so that we are able to identify our bot unassigning contributors from the timeline and conversation and is used here

[0x4007]

Can somebody else corroborate this? I've never heard of this concept and don't think it's a necessary change. @whilefoo rfc

Besides without a linked specification I don't see why this is an authorized project.

[Keyrxng]

Can somebody else corroborate this? I've never heard of this concept and don't think it's a necessary change. @whilefoo rfc

Besides without a linked specification I don't see why this is an authorized project.

#19 introduced here and the at the bottom of the conversation is where it's discussed. I first used the bot username and it was decided to use APP_ID but that does not correlate to the actual user.id of the bot.

[0x4007]

https://chatgpt.com/share/b5dcd678-d466-46a4-95af-9c10c1c9e39b

[Keyrxng]

The confusion is that a github app does not have a user.id, it has an APP_ID but the bot in which that app uses to interact with github is a real user entity with type: Bot and so it does have it's own user.id.

Deleting devpool issues is where I first noticed it, that pr and I wrote more about it there.

[0x4007]

If the following conditions are true we can merge this:

• APP_ID doesn't work for our purposes
• Bot user id is the same on two different organization installations.

[whilefoo]

When fetching comments we do get information about the Github App which includes the APP ID, but in this case we are fetching events which don't include this for some reason.

"performed_via_github_app": {
      "id": 975031,
      "client_id": "Iv23ctBXjJSXqFzuoxRU",
      "slug": "ubiquity-os",
      "node_id": "A_kwHOCYyrXM4ADuC3",
      "owner": {
        "login": "Ubiquity-OS",
        "id": 160213852,
        "node_id": "O_kgDOCYyrXA",
        "avatar_url": "https://avatars.githubusercontent.com/u/160213852?v=4",
        "gravatar_id": "",
        "url": "https://api.github.com/users/Ubiquity-OS",
        "html_url": "https://github.com/Ubiquity-OS",
        "followers_url": "https://api.github.com/users/Ubiquity-OS/followers",
        "following_url": "https://api.github.com/users/Ubiquity-OS/following{/other_user}",
        "gists_url": "https://api.github.com/users/Ubiquity-OS/gists{/gist_id}",
        "starred_url": "https://api.github.com/users/Ubiquity-OS/starred{/owner}{/repo}",
        "subscriptions_url": "https://api.github.com/users/Ubiquity-OS/subscriptions",
        "organizations_url": "https://api.github.com/users/Ubiquity-OS/orgs",
        "repos_url": "https://api.github.com/users/Ubiquity-OS/repos",
        "events_url": "https://api.github.com/users/Ubiquity-OS/events{/privacy}",
        "received_events_url": "https://api.github.com/users/Ubiquity-OS/received_events",
        "type": "Organization",
        "site_admin": false
      },
      "name": "ubiquity-os",
      "description": "AI manager for remote teams",
      "external_url": "https://dao.ubq.fi/ubiquityos-for-daos",
      "html_url": "https://github.com/apps/ubiquity-os",
      "created_at": "2024-08-20T19:23:52Z",
      "updated_at": "2024-08-25T17:28:30Z"
}

I can confirm that bot user id is the same in ubiquibot and ubiquity organizations so I think we can merge this

[whilefoo]

wouldn't it be better to use logger and throw?

[Keyrxng]

You mean instead of posting a comment?

or you mean log const log = ..., addComment(log.logmessage.diff), throw new Error(log.raw)?

[whilefoo]

I mean throw new Error(logger.error(...).diff), then top level catch will post it as a comment

[whilefoo]

It doesn't make sense that the bot merged this if requested changes were not resolved yet

[0x4007]

It doesn't make sense that the bot merged this if requested changes were not resolved yet

Maybe we should require that all threads are resolved. But it seems that this rarely happens in practice, even internally with our own team.

I realize now that there was one approval, so this makes sense that it passed.

Requested changes (whilefoo) sometimes you mark that as the status and then forget to return so it makes sense.

[gentlementlegen]

@whilefoo It was per design, but we can discuss this and change it eventually. I'd say pros are that it keeps PRs moving, cons is that if it is something important it should be taken care of during the review. On the other hand it can be fixed on a later PR as well.

[0x4007]

Just reverted this pull and my Cloudflare Worker deploy works fine. What is the purpose of this pull?