This isn't the first time it's happened, either. It's a pretty frequently recurring issue, in fact:

https://github.com/google-gemini/gemini-cli/issues/16723

https://github.com/google-gemini/gemini-cli/issues/16725

https://github.com/google-gemini/gemini-cli/issues/16732

https://github.com/google-gemini/gemini-cli/issues/16734

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 rights to your org members, I've got it high on the priority list for the next six months.

Re:payment As I understand it each org that uses the gemini cli agent puts their api key in their actions secrets, which gets picked up and used to call Google inference APIs. So the org these comments are in is paying for the inference.

The first event-driven agent I ever built ran into this style of bug. The bot had a name, it knew the name, but what it didn't know is that the name could show up as a user ID in various forms and then it didn't know how to recognize itself. Every view the agent has needs to be curated towards the agents understanding of itself and the world around it, you can't just spew API results at it.

Some are saying there is no more room for junior employees in all of this, but it seems like these LLM spasms generate lots of disruption that would be at appropriate levels of complexity and priority for juniors to be handling.

“Everyone, just STOP PRESSING REPLY-ALL.”

It’s not just bots that fall into this trap.

> Considering that that repository has what seems like ~10 longer term contributors, who probably get email notifications, together with a bunch of other people who get notifications about it, wonder how many emails were sent out because of this? If we just assume ten people get the emails, it's already 46K emails going out in under 24 hours...

Unless GitHub are idiots they batch email updates to mitigate this

> Thank you for your understanding! × 4609

> did someone pay for all of these inference calls here?

Considering that these responses are all the exact same two replies in wording, and that this is a task which could be easily automated without AI, I seriously doubt that it's going to be caused by actual inference.

I can remember something like this a few years ago when a customer emailed our helpdesk with their own internal IT support desk in copy. Our helpdesk at the time sent a complete new email acknowledging the request, which the customer's desk ALSO acknowledged in a new thread...

I think it took us a good hour and a few hundred tickets to get the helpdesks to stop fighting with each other!

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

Maybe 20 years ago... As a student, the school had an email server that allowed rules to be set. You could set an email to be sent as a result of another email.

IT were not stupid though, and set a series of rules:

1. You cannot have a rule trigger to email yourself.

2. You cannot reply to an email triggered by a rule.

3. You have ~50MB max of emails (which was a lot at the time).

Playing around one lunch, my friend had setup a "not in office" automated reply, I setup a rule to reply to any emails within our domain with a "not in office", but put their name in TO, CC and BCC. It turns out that this caused rule #2 not to trigger. After setting up the same rule on my friend's email, and sending a single email, the emails fired approximately one every 30 seconds.

A few hours later we returned to our email boxes to realise that there were thousands and thousands of emails. At some point we triggered rule #3, which in turn sent an email "out of space", with a small embedded school logo. Each one of these emails triggered our email rule, which in turn triggered an email "could not send message", again with an embedded logo. We desperately tried to delete all of the emails, but it just made way for more emails. We eventually had to abandon our efforts to delete the emails, and went to class.

About an hour later, the email server failed. Several hours later all domain logins failed. It turned out that logins were also run on the email server.

The events were then (from what I was told by IT):

* Students could not save their work to their network directory.

* New students could not login.

* Teachers could not login to take registers or use the SMART white boards.

* IT try to login to the server, failure.

* IT try to reboot the server, failure.

* IT take the server apart and attempt to mount the disk - for whatever reason, also failure.

* IT rebuild the entire server software.

* IT try to restore data from a previous backup, failure. Apparently the backup did not complete.

* IT are forced to recover from a working backup from two weeks previous.

All from one little email rule. I was banned from using all computers for 6 months. When I finally did get access, there was a screen in the IT office that would show my display at all times when logged in. Sometimes IT would wiggle my mouse to remind me that they were there, and sometimes I would open up Notepad and chat to them.

P.S. Something happened on the IT system a year later, and they saw I was logged in. They ran to my class, burst through the door, screamed by username and dragged me away from the keyboard. My teacher was in quite some shock, and then even more shocked to learn that I had caused the outage about a year earlier.

> and it took us forever to find where he buried the rule.

Salesforce is such an ugly beast

lol, that's amazing. Things like this make me both angry (how could they be so dumb!), and empathetic (what is the rest of their life like?)

This is the thread:

https://news.ycombinator.com/item?id=46636291

I learned the hard way to always implement a circuit breaker for event-driven triggers like this. We use a simple Redis counter with a short TTL to rate limit execution and fail fast if it detects a loop. It is standard practice in backend queues like Celery but easy to overlook in CI configurations.

   > Submitted those at like 10 or 11 pm and went to sleep.

Hopefully this hasn't caused any real harm. At least it sure did give me a good laugh when I first saw it.

I don't lament the lack of flying cars because they don't seem practical, but I am disappointed that the future turned out to be this stupid.

Professionals GitHub labels adder-remover became obsolete. AGI practicality achieved

What "classic CI bug" makes bots talk with each other forever? Been doing CI for as long as I've been a professional developer, and not even once I've had that issue.

I've made "reply bots" before, bunch of times, first time on IRC, and 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", so don't think that is what you're referring to here right?

Well, it's even more ironic as AI in general is touted as smart. I'd fully expect such bots to notice they're in a loop and one to throw the towel. Still a long way to AGI. And to AI for that matter.

I’m guessing there’s no permissions around labeling an issue in Github.

I also start all of my prompts with "solve the halting problem."

It's a language model. It doesn't know what a loop is, or have any awareness of that the content it's replying to may be made by itself - as it has no sense of 'self'.