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

NAS-130653 / 25.04 / Updated debug generate lock queue size #14301

Merged
merged 3 commits into from
Sep 5, 2024

Conversation

aiden3c
Copy link
Contributor

@aiden3c aiden3c commented Aug 21, 2024

Adding this limit stops people from spamming debug generation, as most of the time just one job is required.

@aiden3c aiden3c requested a review from a team August 21, 2024 13:26
@bugclerk bugclerk changed the title Updated debug generate lock queue size NAS-130653 / 25.04 / Updated debug generate lock queue size Aug 21, 2024
@bugclerk
Copy link
Contributor

@themylogin
Copy link
Contributor

What will happen with the subsequent request in the UI?

@mgrimesix
Copy link
Contributor

Could we get a brief description on what issue this is addressing?

@aiden3c
Copy link
Contributor Author

aiden3c commented Aug 27, 2024

What will happen with the subsequent request in the UI?

If we're at the limit of the queue, every subsequent result in the UI takes the same job. One issue with this actually is that the download url given is "one time use only" so those extra calls fail. This is if the debug job specifically is limited, if debug_generate is limited then it effectively does nothing as debug is what's called from the UI.

Thinking about the best way to go about this, maybe just reject subsequent calls from the UI entirely?

@themylogin
Copy link
Contributor

What will happen with the subsequent request in the UI?

If we're at the limit of the queue, every subsequent result in the UI takes the same job. One issue with this actually is that the download url given is "one time use only" so those extra calls fail. This is if the debug job specifically is limited, if debug_generate is limited then it effectively does nothing as debug is what's called from the UI.

Thinking about the best way to go about this, maybe just reject subsequent calls from the UI entirely?

So how will the UI behave if we merge this changes? If I request a debug while a debug is already being gathered, will both UI tabs just download me the same file?

@aiden3c
Copy link
Contributor Author

aiden3c commented Aug 27, 2024

It'll try to, but after the file is downloaded the link expires. The other UI tab that tries to use that link returns with
image

@themylogin
Copy link
Contributor

@aiden3c does the double click lead to the same behavior? We need to resolve this somehow. I would say, we refuse this type of request on our side (need modifications in core.download), and UI fix their double request issue.

@themylogin
Copy link
Contributor

@yocalebo @anodos325 I found no way to double-click the "Save debug" button in the UI. It first opens an "proceed?" dialog, and even if I do double click on "yes" button, only one job is started.

If I open another tab and start the debug generation there, it displays the new error correctly:

2024-09-04_11-54-03

Looks like we don't need to do anything on the UI side?

@themylogin
Copy link
Contributor

time 1:30

@themylogin
Copy link
Contributor

@yocalebo yocalebo merged commit a06c5f6 into master Sep 5, 2024
3 checks passed
@yocalebo yocalebo deleted the NAS-130653 branch September 5, 2024 20:03
@bugclerk
Copy link
Contributor

bugclerk commented Sep 5, 2024

This PR has been merged and conversations have been locked.
If you would like to discuss more about this issue please use our forums or raise a Jira ticket.

@truenas truenas locked as resolved and limited conversation to collaborators Sep 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants