4 ms·

Thank you. I've been following these family of bugs for what feels like years (although this specific one has _only_ been open 6 years): https://gitlab.com/gitl

Thank you. I've been following these family of bugs for what feels like years (although this specific one has _only_ been open 6 years): https://gitlab.com/gitlab-org/gitlab/-/issues/16448 https://gitlab.com/gitlab-org/gitlab/-/issues/16448 Typing out 85 review comments and having them swallowed by a 500 response because the frontend thought that of course XHRs are always 200 OK, why wouldn't they be? is indescribably infuriating

polskibus 4y ago
try VSCode plugin for reviewing large MRs.
- mdaniel 4y ago
  Thank you for your suggestion. I don't want to locally clone every project and then checkout every branch of MRs assigned to me just to work around their XHR issues If I had more energy, I'd try that on some big MR to just to find out whether their stupid extension also just assumes all XHRs are 200 OK. That'd be some icing on the cake
ZephyrBlu 4y ago
What the hell. I'd be extremely pissed off if that happened to me. Does GitLab not save reviews as you go like GitHub seems to?
- mdaniel 4y ago
  It "saves" them in that they are persisted on the server (as best I can tell) but the sequence is 1. POST /review/temp 1. POST /review/temp # all done, submit the batch 1. POST /review/submit <- 500 Oops we sorrwweee # now every comment is gone I don't recall this second whether the actual sequence is "POST" followed by "DELETE /review/temp" meaning this is 100% a JS bug or whether it's "POST" and the controller for submit nukes the temp version, making it a ruby bug And yes, "extremely pissed" isn't strong enough but ... put it on the list of the other 48,000 issues, I guess