Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems retrying 3400 workorders from the start #2363

Open
taylordowns2000 opened this issue Aug 8, 2024 · 0 comments · May be fixed by #2508
Open

Problems retrying 3400 workorders from the start #2363

taylordowns2000 opened this issue Aug 8, 2024 · 0 comments · May be fixed by #2508
Assignees
Labels
bug Newly identified bug

Comments

@taylordowns2000
Copy link
Member

Here's the story:

  1. Around 12:11:00 UTC on August 7th I "selected all" work orders for a particular workflow from the history page.
  2. I opened the "retry" modal and it asked if I'd like to retry the 10 on this page, or all 3418 that match the query.
  3. I chose to retry all 3418 from the start.
  4. When I clicked retry all, the button greyed out and the page just sat there.... no response.
  5. Eventually, I clicked away to another page.
  6. When I went to the workflows overview page for my project, I could see that (over the course of about 2 minutes) the number of enqueued runs climbed up to 1695.
  7. When I navigated back to the history page, the page was left blank. (Loading work orders.)

In the end, it feels like there are at least 3 things happening:

  1. The form submission in the retry modal seems like it might be waiting until everything is done in the DB before closing. If that's the case, we should instead replicate the v1 behaviour where we send a request to the backend, return some sort of :ack, and then finally notify via toast when all WOs have been re-enqueued—or notify via toast if there's a failure. But the idea is that it should be async.
  2. 3418 were requested to be retried, but only 1695 got enqueued. 🫤
  3. The history page may be cracking under big retry load, making it impossible to see what's going on at a moment when we'd expect users to be watching, hawk-eyed, on the history interface,
@taylordowns2000 taylordowns2000 added the bug Newly identified bug label Aug 8, 2024
@jyeshe jyeshe linked a pull request Sep 17, 2024 that will close this issue
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Newly identified bug
Projects
Status: In review
Development

Successfully merging a pull request may close this issue.

2 participants