[eyelidlessness]

They seemed fairly surprised by the fact it happened, and let it go on for some time. Which strongly suggests they hadn’t considered such a load test on their own. If I had a budget/head count, I’d at minimum put out a feeler for a QA role.

[adamckay]

But the next largest legitimate repo is going to be something like 20M commits shy of that, so it seems like it's excellent that GH engineers only just started to care.

It's entirely possible that such a load test has been considered, but deemed non-realistic so not prioritised for some time. If I were running the QA team I'd be annoyed if time were spent on abusive destructive testing than realistic testing that real-world users may experience, especially because load testing like this would have to be on an identical environment to PROD so rather expensive.

It reminds me of that old QA joke:

A QA engineer walks into a bar and orders a beer. She orders 2 beers.

She orders 0 beers.

She orders -1 beers.

She orders a lizard.

She orders a NULLPTR.

She tries to leave without paying.

Satisfied, she declares the bar ready for business. The first customer comes in an orders a beer. They finish their drink, and then ask where the bathroom is.

The bar explodes.

[blowski]

In your joke, QA was only doing exploratory testing. Somebody - perhaps the builders, bar staff, or QA - should have also been doing integration testing for key user stories, and the system has failed because nobody ensured that was happening.

GitHub hasn't failed here - it continued to perform at normal levels for other users, so far as I can see, and they had an upstream process which caught the issue without the system failing. Maybe some exploratory testing had previously identified where that process should kick in, but without having an automated process since it was so unlikely to happen.

[rewmie]

> Which strongly suggests they hadn’t considered such a load test on their own.

Not really. GitHub has been around for over a decade. People bother with problems that have a realistic chance of happening. If GitHub didn't bothered to rate limit commits it means it was a potential issue that didn't manifested itself for over a decade.

People tend to bother about problems that happen. Otherwise everyone would be freaking out because of killer asteroids.

[sverhagen]

Where are you reading that they're surprised?

[eyelidlessness]

They asked with more than passable benefit of the doubt what the user intended. And they asked quite a ways after the user noticed local degradation. “Surprised” might be the wrong term, but it definitely doesn’t seem like a specific guard was in place for the scenario.

[rewmie]

Was there a guard needed? I don't think so. It seems GitHub didn't saw any degraded performance and barely noticed the issue, and odds are they presumed the author screwed up with their GitHub actions configuration. Once they determined it was plain old abuse, I'd guess some GitHub employee said "what a moron" and proceeded with his day.

[eyelidlessness]

What are you basing this on?

[rewmie]

> What are you basing this on?

To start off, based on the fact that GitHub is around for over a decade and this was the first time this sort of attention-seeking stunt was made public.

Do you have any indication this sort of stunt is relevant?