in the old days one would add and check for a loop detection token when loops like this could be driven by external systems... i wonder if today it would be as simple as adding "ensure you don't get stuck in any loops" to a prompt. fwiw. doesn't look like gemini at all, the responses are perfectly canned... maybe just good old fashioned ci rules.
It looks like the status/need-triage label was removed
51–60 of 87 posts
Re: It looks like the status/need-triage label was removed
#52Earlier quoted context omitted.
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…
You were not the root cause of that outage. > IT were not stupid Everything else you described points to them being blundering morons. From an email forwarder that didn’t build loop detection into its header prepending, fucking up a restore, and then malware’ing the student that exposed them into kafkaesque technology remand, all I’m taking away here is third-degree weaponised incompetence
I remember IT were continuously fixing computers/laptops broken by students, fixing connectivity issues (maybe somebody has pushed crayons into the Ethernet ports), loading up software that teachers suddenly need tomorrow, etc. Maybe they also have to prevent external actors from accessing important information. All the whilst somebody well above your pay grade is entering into software contracts without knowing anything about software.
Things are likely far more plug & play now for IT infrastructure, back then (XP I think) it was more the Wild West. Only five years ago I know that a University login system used to send username and password credentials via plaintext, because that's how the old protocols worked. The same University also gave me sudo to install/run programs, which provided sudo over all network drives.
You would probably be horrified to know how much infrastructure still runs on outdated stuff. Just five years ago the Chinese trains stopped working because Adobe disabled Flash [1]. I know of some important infrastructure that still uses floppy disks. Not so long ago some electrical testing could not be conducted because the machine that performed it got a corrupted floppy disk.
[1] https://arstechnica.com/tech-policy/2021/01/deactivation-of-...
Re: It looks like the status/need-triage label was removed
#53Earlier quoted context omitted.
If you’re making a bot in which there will be many sub-behaviors, it can be tempting to say “each sub-behavior should do whatever checks it needs, including basic checks for self-reply.” And there lie dragons, because whether a tired or junior or (now) not-even-human engineer is writing new sub-behavior, it’s easy to assume that footguns either don’t exist or are prevented a layer up. There’s nothing more classic tha…
I'm kind of understanding, I think, but not fully. Regardless of how you structure this bot, there will be one entrypoint for the webhooks/callbacks, right? Even if there is sub-behaviours, the incoming event is passing through something, or are we talking about "sub-bots" here that are completely independent and use different GitHub users and so on? Otherwise I still don't see how you'd end up with your own bot gett…
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.Re: It looks like the status/need-triage label was removed
#54Re: It looks like the status/need-triage label was removed
#55Edit: there's actually a PR, but this is one of those repos where for some reason, they require every PR to have an associated issue. And in this case, they aren't even linked...
Re: It looks like the status/need-triage label was removed
#56Earlier quoted context omitted.
If you’re making a bot in which there will be many sub-behaviors, it can be tempting to say “each sub-behavior should do whatever checks it needs, including basic checks for self-reply.” And there lie dragons, because whether a tired or junior or (now) not-even-human engineer is writing new sub-behavior, it’s easy to assume that footguns either don’t exist or are prevented a layer up. There’s nothing more classic tha…
I'm kind of understanding, I think, but not fully. Regardless of how you structure this bot, there will be one entrypoint for the webhooks/callbacks, right? Even if there is sub-behaviours, the incoming event is passing through something, or are we talking about "sub-bots" here that are completely independent and use different GitHub users and so on? Otherwise I still don't see how you'd end up with your own bot gett…
Someone sets up a bot with: on a trigger, read the message, determine which "skill" to use out of a set of behaviors, then let that skill handle all the behavior about whether or not to post.
Later, someone (or a vibe coding system) rolls out a new skill, or a change to the skill, that omits/removes a self-reply guard, making the assumption that there are guards at the orchestration level. But the orchestration level was depending on the skill to prevent self-replies. The new code passes linters and unit tests, but the unit tests don't actually mimic a thread re-triggering the whole system on the self-posting. New code gets yolo-pushed into production. Chaos ensues.
Re: It looks like the status/need-triage label was removed
#57It'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…
> 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.
This is just two github actions conflicting with each other, one that auto-labels with "status/need-triage" and the other that incorrectly sees gemini-cli as lacking the permission to do that.
The fix looks like it was https://github.com/google-gemini/gemini-cli/pull/16762 because the bot adding labels wasn't passing the org-level ownership check they used at first.
Re: It looks like the status/need-triage label was removed
#58Re: It looks like the status/need-triage label was removed
#59Earlier quoted context omitted.
You were not the root cause of that outage. > IT were not stupid Everything else you described points to them being blundering morons. From an email forwarder that didn’t build loop detection into its header prepending, fucking up a restore, and then malware’ing the student that exposed them into kafkaesque technology remand, all I’m taking away here is third-degree weaponised incompetence
Yes and no. This was the IT of a school, most likely low-paid College/University graduates trying to patch together a working system on a shoe-string budget 20 years ago. Maybe they were fully aware of the issues and struggled to get time to deal with them - try convincing an uneducated management that you need to fix something that is currently working. I remember IT were continuously fixing computers/laptops broken…
Re: It looks like the status/need-triage label was removed
#60Earlier quoted context omitted.
“Everyone, just STOP PRESSING REPLY-ALL.” It’s not just bots that fall into this trap.
The linked issue literally only have one bot falling into that trap...