5 ms·

For the record, it's failing silently, too, showing e.g. "There aren’t any open pull requests." even though there are dozens. That's pretty bad, this will defin

by cromka 6mo ago

For the record, it's failing silently, too, showing e.g. "There aren’t any open pull requests." even though there are dozens. That's pretty bad, this will definitely mislead people.

techterrier 6mo ago
speak for yourself, we are celebrating having completed all our PR's for a change :D
dclowd9901 6mo ago
Or last week's "If you use merge queue, oopsie, we accidentally destroyed your trunk", which also failed silently.
- elischleifer 6mo ago
  We happen to build the perfect solution to avoiding GitHubs Merge Queue - ours :) It’s also massively more performant https://trunk.io/merge-queue https://trunk.io/merge-queue
  - rileymichael 6mo ago
    while external merge queues offer a ton more features, i wouldn't describe any of them as 'perfect' based on the simple fact the UX is bolted on. github continues to display their native UI components for merging, and users are forced to interact via arcane commands in comments or external CLIs/webpages. not ideal!
- scottbez1 6mo ago
  I was surprised that incident didn’t seem to get as much attention since that was a pretty major data corruption bug, but I guess it was a much smaller scope of impacted repos/customers than a lot of these availability issues?
  - dclowd9901 6mo ago
    Without reaching for my tin foil hat, I have a feeling MS is able to suppress these incidents somehow, because yeah, that one was pretty bad.
    - bonesss 6mo ago
      Wrapping my face in tinfoil: across the board, Amazon, Microsoft, GitHub, Anthropic and OpenAI, I’m seeing a lot of top-level service issues that sound an awful lot like code hitting production that hasn’t been fully tested. Breaking buttons on the website is one thing, kinda, but Enterprise used to mean a certain degree of robustness and seriousness in product management.
      - serial_dev 6mo ago
        Devs are expected to ship slop 10x faster. The AI tools genuinely help a bit, like maybe 2x, but the 10x "improvement" comes from not thinking about anything else than shipping your assigned features, not testing your code carefully, not getting proper code reviews, not dogfooding your stuff, and releasing carelessly.
  - yearolinuxdsktp 6mo ago
    Merge queues are not as frequently used… ~2000 PRs affected over 4 hours. I reckon that’s on the order of 10 commits per tenant. It’s a feature with low traction, probably because it creates more problems than it solves.
    - move-on-by 6mo ago
      Merge queues are great. The bug only affected repos using merge queues AND squash/rebase merging (instead of the default merge commit)
  - MarkMarine 6mo ago
    Definitely got attention during the prod outage at my work. I’m going to find another alternative, I’m sick of this terrible uptime.
enraged_camel 6mo ago
Even when it does show the PR list, it doest necessarily show all the PRs in the category being viewed. Truly nasty issue.

by cromka 6mo ago

For the record, it's failing silently, too, showing e.g. "There aren’t any open pull requests." even though there are dozens. That's pretty bad, this will definitely mislead people.

techterrier 6mo ago

speak for yourself, we are celebrating having completed all our PR's for a change :D

dclowd9901 6mo ago

Or last week's "If you use merge queue, oopsie, we accidentally destroyed your trunk", which also failed silently.

elischleifer 6mo ago
We happen to build the perfect solution to avoiding GitHubs Merge Queue - ours :) It’s also massively more performant https://trunk.io/merge-queue https://trunk.io/merge-queue
- rileymichael 6mo ago
  while external merge queues offer a ton more features, i wouldn't describe any of them as 'perfect' based on the simple fact the UX is bolted on. github continues to display their native UI components for merging, and users are forced to interact via arcane commands in comments or external CLIs/webpages. not ideal!
scottbez1 6mo ago
I was surprised that incident didn’t seem to get as much attention since that was a pretty major data corruption bug, but I guess it was a much smaller scope of impacted repos/customers than a lot of these availability issues?
- dclowd9901 6mo ago
  Without reaching for my tin foil hat, I have a feeling MS is able to suppress these incidents somehow, because yeah, that one was pretty bad.
  - bonesss 6mo ago
    Wrapping my face in tinfoil: across the board, Amazon, Microsoft, GitHub, Anthropic and OpenAI, I’m seeing a lot of top-level service issues that sound an awful lot like code hitting production that hasn’t been fully tested. Breaking buttons on the website is one thing, kinda, but Enterprise used to mean a certain degree of robustness and seriousness in product management.
    - serial_dev 6mo ago
      Devs are expected to ship slop 10x faster. The AI tools genuinely help a bit, like maybe 2x, but the 10x "improvement" comes from not thinking about anything else than shipping your assigned features, not testing your code carefully, not getting proper code reviews, not dogfooding your stuff, and releasing carelessly.
- yearolinuxdsktp 6mo ago
  Merge queues are not as frequently used… ~2000 PRs affected over 4 hours. I reckon that’s on the order of 10 commits per tenant. It’s a feature with low traction, probably because it creates more problems than it solves.
  - move-on-by 6mo ago
    Merge queues are great. The bug only affected repos using merge queues AND squash/rebase merging (instead of the default merge commit)
- MarkMarine 6mo ago
  Definitely got attention during the prod outage at my work. I’m going to find another alternative, I’m sick of this terrible uptime.

enraged_camel 6mo ago

Even when it does show the PR list, it doest necessarily show all the PRs in the category being viewed. Truly nasty issue.