APPENG-5698: add per-user concurrent request limiting to analysis queue - #286
Merged
zvigrinberg merged 4 commits intoJul 28, 2026
Conversation
gnetanel
requested review from
IlonaShishov,
rhartuv,
vbelouso and
zvigrinberg
as code owners
July 27, 2026 11:09
Collaborator
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
gnetanel
force-pushed
the
APPENG-5698_limit_users_requests_squashed2
branch
from
July 27, 2026 11:18
0e1346a to
c503fdf
Compare
…is queue A single authenticated user could submit enough large SBOM analysis requests to fill every slot in the global active-request queue, starving all other users for up to the queue timeout (T-011). RequestQueueService now tracks active requests per user identity in addition to the existing global count, and rejects a user's new submission with a UserQueueExceededException (mapped to HTTP 429) once they hit a configurable per-user limit (exploit-iq.queue.max-active-per-user, default 5). Pending requests retain their owning user so the limit is still enforced when they are promoted from the pending queue to active. - RequestQueueService: add max-active-per-user config, per-user active tracking (activeByUser/activeUserById), and PendingRequest record to carry user identity through the pending queue - ReportService: pass resolved user identity into queue() for both submit() and retry(), and surface UserQueueExceededException as a distinct report error state - ReportEndpoint/ProductEndpoint: map UserQueueExceededException to HTTP 429 with a dedicated message - ComponentProcessingService: distinguish per-user limit errors in component submission failure messages - AppConfig/application.properties/docs: document the new max-active-per-user setting reduce quarkus.http.limits.max-body-size from 300M to 90M. Maximum SPDX SBOM product in redhat is 87MB… ( openshift version 4.15 ). Add unit-tests Fix review note 2 - sync concerns Code review fix: Update active, activeUserById, activeByUser ConcurrentHashMap during application startup On applicatino crash/stopped - init the active, activeUserById, activeByUser ConcurrentHashMap with the current scan on the system. Code review fix: Use @ServerExceptionMapper for queue exceptions in ReportEndpoint Replace duplicated try/catch blocks for RequestQueueExceededException and UserQueueExceededException in process(), newRpmReport(), and submit() with class-level @ServerExceptionMapper methods, matching the pattern already used in ProductEndpoint. Ensures all three endpoints return the same 429 status and error message instead of process()/newRpmReport() using a hardcoded message while submit() returned e.getMessage(). Fix review note bug fix: Also calculate pending user request when checking user limits Review fix: enhance syncrnoizaton using user logk and not generic logs Fix code review: Remove reflection from unit-tests rebase fixes Code review fixes fix unit-tests Add debug logs
gnetanel
force-pushed
the
APPENG-5698_limit_users_requests_squashed2
branch
from
July 27, 2026 11:37
c503fdf to
bb8256f
Compare
zvigrinberg
requested changes
Jul 27, 2026
zvigrinberg
left a comment
zvigrinberg
left a comment
Collaborator
There was a problem hiding this comment.
@gnetanel Very good job...
Only 2 minor issues left..
Please take a look..
Thanks.
| public void deleted(String id) { | ||
| LOGGER.debugf("Removed deleted report %s. Removing from active queue.", id); | ||
| active.remove(id); | ||
| removeActive(id); |
Collaborator
There was a problem hiding this comment.
@gnetanel You're assuming that only active reports can be deleted, like it was before.
Let's keep it that way, but add documentation so it will be known that we're not supporting pending reports removal.
| } catch (Exception e) { | ||
| // Release the slot reserved above so a failing onAdmitted callback (e.g. a failed DB | ||
| // write) doesn't permanently consume queue capacity. | ||
| if (sendNow) { |
Collaborator
There was a problem hiding this comment.
@gnetanel I'm missing here a warning/error log message that explains what went wrong on the onAdmiited.run() callback invocation.. ( before it's removing the slots from the queues).
zvigrinberg
approved these changes
Jul 28, 2026
zvigrinberg
left a comment
zvigrinberg
left a comment
Collaborator
There was a problem hiding this comment.
@gnetanel LGTM Approved.
Thanks for the great work!.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A single authenticated user could submit enough large SBOM analysis
requests to fill every slot in the global active-request queue,
starving all other users for up to the queue timeout (T-011).
RequestQueueService now tracks active requests per user identity in
addition to the existing global count, and rejects a user's new
submission with a UserQueueExceededException (mapped to HTTP 429)
once they hit a configurable per-user limit
(exploit-iq.queue.max-active-per-user, default 5). Pending requests
retain their owning user so the limit is still enforced when they are
promoted from the pending queue to active.
RequestQueueService: add max-active-per-user config, per-user active
tracking (activeByUser/activeUserById), and PendingRequest record to
carry user identity through the pending queue
ReportService: pass resolved user identity into queue() for both
submit() and retry(), and surface UserQueueExceededException as a
distinct report error state
ReportEndpoint/ProductEndpoint: map UserQueueExceededException to
HTTP 429 with a dedicated message
ComponentProcessingService: distinguish per-user limit errors in
component submission failure messages
AppConfig/application.properties/docs: document the new
max-active-per-user setting
In addition - max-body-size has been reduced from 300M to 90M