To be clear, is AI actually at play here, aside from the fact that the repo is for Gemini? It just looks like two simple rules that interact poorly, that we could've seen in 2015.
It looks like the status/need-triage label was removed
71–80 of 87 posts
Re: It looks like the status/need-triage label was removed
#72I think the real irony is an LLM trying to enforce permissions at all. Why is it doing that? If the tag exists, the user had the permission to create it, no?
Re: It looks like the status/need-triage label was removed
#73It's easy to miss, but in the middle of the page: > 4609 remaining items Seems gemini-cli and gemini-cli didn't understand who themselves were, so they though someone else added/removed the label, which it tried to correct, which the other then tried to correct, which the other... Considering that that repository has what seems like ~10 longer term contributors, who probably get email notifications, together with a b…
Re: It looks like the status/need-triage label was removed
#74Earlier quoted context omitted.
I only used salesforce once (was “forced” to use it haha) and it was mind boggling how anyone would ever want to use it or even become an expert in using it. I’d rather track everything in a giant excel tyvm
You become an expert in using SalesForce, or SAP, for the same reason you get a medical license in the US. There’s a limited number of you who are willing to traverse that gauntlet of abuse, so you know you’ll always have work.
Re: It looks like the status/need-triage label was removed
#75Earlier quoted context omitted.
The owner is a Google employee, but for the sake of safety it should be owned by a real Google org. I've just asked them to migrate it to their OSS org. Unfortunately the app creation flow on GitHub makes it impossible (for now) for a normal org user to create an app for the org, so apps end up getting created on personal accounts and become load bearing. We've got a work item to make it possible to give app creation…
Dear god. This reminds me of all of the things in Google that are "load bearing" and have to be owned by random gmail accounts instead of formal service accounts or org accounts. How long has this one been on the roadmap for? (since you actually work for github)
It's part of the push we've been making over the last year or two to improve custom roles and finer-grained authorization for resources.
Re: It looks like the status/need-triage label was removed
#76Script author here :-) This was due to two different GitHub Action workflows: (Workflow 1): Remove the need-triage label under certain conditions. (Workflow 2): If anyone outside a project maintainer removes a label, re-add it with a friendly message explaining why. Submitted those at like 10 or 11 pm and went to sleep. Woke up to all issues that got changed overnight with dozens, hundreds, or thousands of these mess…
> Submitted those at like 10 or 11 pm and went to sleep.
That's a classic :)Hopefully this hasn't caused any real harm. At least it sure did give me a good laugh when I first saw it.
Re: It looks like the status/need-triage label was removed
#77Earlier quoted context omitted.
1. Set up a bot that runs on every new comment on a PR 2. The bot comments something on that PR Doesn't have to be more advanced than this to get an infinite loop if you don't build anything where it ignores comments from itself or similar.
Previously: > pretty much the second or third step is "Huh, probably this shouldn't be able to reply to itself, then it'll get stuck in a loop". But that's hardly a "classic CI bug",
I don't see why it's not a "classic CI bug". It's an easy trap to fall into, and I've seen it multiple times. Same with "action that runs on every commit to main to generate a file and push a new commit if the file changes", that suddenly gets stuck in a loop because the generated file contains a comment with the timestamp of creation.
Re: It looks like the status/need-triage label was removed
#78Earlier quoted context omitted.
Yeah, a bot replying to itself is pretty poor design. It's one of the first things you do even with toy bots. You can even hardcode knowing itself, since usually you have an unchanging ID. A much more common problem is if someone deploys another bot, which will lead your bot into having an endless back-and-forth with it.
> A much more common problem is if someone deploys another bot, which will lead your bot into having an endless back-and-forth with it. This I'd understand, bit trickier since you're basically end up with a problem typical of distributed systems. But one bot? One identity? One GitHub user? Seems really strange to miss something like that, as you say, it's one of the earlier things you tend to try when creating bots f…
Re: It looks like the status/need-triage label was removed
#79It's easy to miss, but in the middle of the page: > 4609 remaining items Seems gemini-cli and gemini-cli didn't understand who themselves were, so they though someone else added/removed the label, which it tried to correct, which the other then tried to correct, which the other... Considering that that repository has what seems like ~10 longer term contributors, who probably get email notifications, together with a b…
> Thank you for your understanding! × 4609
Re: It looks like the status/need-triage label was removed
#80Earlier quoted context omitted.
The linked issue literally only have one bot falling into that trap...
The quote is from one of the old "mail storm" stories out there. Where someone miss-configures something, someone e-mails a list, people are out of office, people reply-all, and hilarity ensues. Plenty of them posted on slashdot and the like back in the day.