Live data from Hacker News

It looks like the status/need-triage label was removed

github.com

51–60 of 87 posts

Re: It looks like the status/need-triage label was removed

#51
post #28

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'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'.

Re: It looks like the status/need-triage label was removed

#52
post #40

Earlier 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

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 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

#53
post #8

Earlier 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

#54
Ironically this is type of issue is common in pre-LLM (rules-based) AI. Given that the back-and-forth messages are the same, I suspect they're generated by a small script, not an LLM. But I wouldn't be surprised if the script was created mostly or entirely by an LLM.

Re: It looks like the status/need-triage label was removed

#55
Maybe I'm missing something, but this seems to be an issue report claiming to be a PR? Where's the patch?

Edit: 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

#56
post #8

Earlier 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…

Sorry, could have been more clear.

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

#57
post #31

It'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.

Yeah, this looks more fun than it is because the bot is named "gemini-cli".

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

#59
post #52

Earlier 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…

Ah well having operated at all levels of institutional hierarchies I include the hapless/indifferent management within functional and operational scope of the term “IT”, and they are accountable in any case, however understanding you choose to be of the struggling folks at the pointy end. So there’s your root cause.

Re: It looks like the status/need-triage label was removed

#60
post #24

Earlier 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...

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.
Post reply on HN