Live data from Hacker News

GitHub is investigating an incident with Pull Requests, Issues and Webhooks

githubstatus.com

51–60 of 61 posts

Re: GitHub is investigating an incident with Pull Requests, Issues and Webhooks

#51

Earlier quoted context omitted.

They should understand this. If users move away who’s code will the rinse and resell?

Move where exactly? Bitbucket and GitLab aren't that great either. I'm affected by GitHub outages maybe once every 2 months for a couple of hours. Sure, various parts go down but it's never something super impactful to my workflow. It's not great but, IMHO, not outrage worthy.

I am not particularly keen on github and microsoft scraping my code and re-selling it via copilot. If you own mission critical ip you can always spin up a vm and setup reliable backups using gitlab, or simply via ssh. It really is that easy to move away.

Re: GitHub is investigating an incident with Pull Requests, Issues and Webhooks

#52

Outages, forced 2FA bullshit, half-wit AI feature because buzzword... all this makes long term customers want to self host. Can someone drop a hint to the CEO please: WE PAY YOU TO BE BORING AND STABLE.

> forced 2FA bullshit... all this makes long term customers want to self host.

An objectively positive security feature makes people want to self host?

Re: GitHub is investigating an incident with Pull Requests, Issues and Webhooks

#53

Outages, forced 2FA bullshit, half-wit AI feature because buzzword... all this makes long term customers want to self host. Can someone drop a hint to the CEO please: WE PAY YOU TO BE BORING AND STABLE.

> forced 2FA bullshit... all this makes long term customers want to self host. An objectively positive security feature makes people want to self host?

I don't trust security people to do sane things. - Linus Torvalds (2017)

Specifically, if you have a happy client paying you monthly who has established a functional workflow and no problems, how is forcibly breaking that based on a series of bullshit assumptions (eg. customer has a static phone number in one country that they have continuous SMS access to, customer wants to install your extra app, whatever) for the nominal benefit of some theoretical attack category a smart idea?

It's fine to offer the migration, even to encourage it. But to insist is both wrong and bad for business.

Re: GitHub is investigating an incident with Pull Requests, Issues and Webhooks

#54

Earlier quoted context omitted.

> forced 2FA bullshit... all this makes long term customers want to self host. An objectively positive security feature makes people want to self host?

I don't trust security people to do sane things. - Linus Torvalds (2017) Specifically, if you have a happy client paying you monthly who has established a functional workflow and no problems, how is forcibly breaking that based on a series of bullshit assumptions (eg. customer has a static phone number in one country that they have continuous SMS access to, customer wants to install your extra app, whatever) for the…

> eg. customer has a static phone number in one country that they have continuous SMS access to, customer wants to install your extra app, whatever

GitHub uses TOTP which does not require SMS, can be used with dozens of apps (because it's a protocol), and can be easily transfered using QR codes or seeds.

Re: GitHub is investigating an incident with Pull Requests, Issues and Webhooks

#55
post #15

Web hooks are not reliable. When engineering your system, you need to implement a scheduled based watcher to go back and clean up hook issues.

I gave up trying to be a polite API consumer with GitHub events, etc. Polling the basic resources every minute is way more reliable and your code will survive a junior developer's shenanigans. I had the REST API e-tag polling working well, but then I discovered my org event stream didn't include label changes. This is a separate thing I needed to poll and at that point I lost my mind. I refuse to keep track of 6+ pie…

It's part of the Shopify and BigCommerce's design pattern explicity. Like, yes we offer webhooks, but also you need to come back once an X (I typically do hourly) and sweep for missed data.

Not to mention with Shopify, webhooks are not guaranteed to be at all ordered. You may receive an order.updated event prior to an order.create event. Delivery milage and timing may vary.

So, after all that back and forth we asked ourselves, why do we even bother with webhooks?

Well for one, it helps our clients being real time to improve their shipping speed, keeping real time inventory, and so forth. Secondly, it keeps our processing more flat. We might run an hourly cron to pickup stragglers, but we don't do huge data dumps per hour. In some our busier systems it can be a real challenge when clients do things like monthly invoicing all their customers. Using webhooks and processing records as they come in keeps the queue as small as reasonable.

Re: GitHub is investigating an incident with Pull Requests, Issues and Webhooks

#56
post #31

Earlier quoted context omitted.

My screwdriver doesn’t seem to need more features. It’s nice stable and reliable.

Before the MS acquisition, Github didn't even have emoji reactions on comments in issue threads, so people just spammed +1s if they had the same issue. It was terrible. (You can still see evidence of this on older repos.) They also didn't have like 5 billion other features that we now take for granted. EDIT: Sorry, this is incorrect. GH did ship them prior to the MS acquisition. I do however remember them taking an E…

> Before the MS acquisition, Github didn't even have emoji reactions.

I have never, ever in my professional life thought “I need an emoji for this”

Re: GitHub is investigating an incident with Pull Requests, Issues and Webhooks

#57

Frustrating and unproductive day for those trapped in CI driven development mode. Mild annoyance for the rest of us.

I have never worked, or know someone who has, at a place that doesn't rely on CI (does that make it CIDD?). Of all the *DDs, this is one of the few that is done without much complaint or major problems or controversies around it.

Ever see a PR with 50-100 commits in short succession with messages like “fix”? That’s CIDD.

Re: GitHub is investigating an incident with Pull Requests, Issues and Webhooks

#58

Maybe I wasn't paying attention as much but I never remember Github having this high a frequency of outages before Microsoft bought them.

Am I the only one that remembers frequent outages before the acquisition? I didn't keep track in a spreadsheet or anything so don't have any data to back it up though but always assumed it's similar to Twitter of the day, hard to make a stable service in Rails.

If anyone can actually put out the data that would be great. I suspect there was a period post acquisition of relative stability that dulls our memory of frequently broken PRs which we probably just got used to at the time.

Re: GitHub is investigating an incident with Pull Requests, Issues and Webhooks

#59

Earlier quoted context omitted.

I don't trust security people to do sane things. - Linus Torvalds (2017) Specifically, if you have a happy client paying you monthly who has established a functional workflow and no problems, how is forcibly breaking that based on a series of bullshit assumptions (eg. customer has a static phone number in one country that they have continuous SMS access to, customer wants to install your extra app, whatever) for the…

> eg. customer has a static phone number in one country that they have continuous SMS access to, customer wants to install your extra app, whatever GitHub uses TOTP which does not require SMS, can be used with dozens of apps (because it's a protocol), and can be easily transfered using QR codes or seeds.

Also, they support Passkeys. Which is by all metrics a vastly superior way to secure an account compared to normal passwords.

Re: GitHub is investigating an incident with Pull Requests, Issues and Webhooks

#60
post #46

Earlier quoted context omitted.

Before this gets downvoted, are there any notable features that could only have been added thanks to the Microsoft acquisition? I think GitHub actions are pretty successful, which may not have been developed by Microsoft as it was launched right after acquisition, but I guess it's easier to keep free since it runs on their own hardware. I don't immediately see copilot as a GitHub feature, but maybe that'll change for…

I think you're asking a slightly incorrect question. Very few features could "only" be added thanks to the MS acquisition. What you really want to know is how many more features were added, thanks to MS. Or, how much longer would those features have taken to be built if GitHub was not acquired by MS. My gut feeling, seeing GH pre- and post-acquisition, says that a lot of the stuff they shipped post-MS would simply ne…

> * that extremely useful fuzzy-find that repos have (press t in any repo)

They shipped that in 2011[1]

[1]: https://github.blog/2011-02-10-introducing-the-file-finder/

Post reply on HN