Conversation
…not check their completion status via notifications or bom status. This is existing behaviour, setting wait to true was a noop.
…utNotificationTaskRange. Prevents call to notifications API for which the results were never used downstream, CodeLocationCreationData's NotificationTaskRange is null.
8477775 to
9036a70
Compare
9036a70 to
5f4efc0
Compare
…rsion exists and is at least 2023.1.1 which has reached end of service.
4b1c584 to
784a008
Compare
…red a waitable (via notifications).
76512a3 to
74c9aa5
Compare
32756b4 to
08a210c
Compare
08a210c to
01329b3
Compare
dterrybd
reviewed
Apr 14, 2026
shantyk
commented
Apr 14, 2026
| failedScans.add(output.getCodeLocationName()); | ||
| handleNoScanStatusFile(scassScan, scanOutputLocation); | ||
| return; | ||
| } |
Contributor
Author
There was a problem hiding this comment.
Just moved to make try/catch block tighter around different exceptions expected, instead of one big umbrella try/catch.
dterrybd
reviewed
Apr 14, 2026
dterrybd
approved these changes
Apr 14, 2026
devmehtabd
approved these changes
Apr 14, 2026
| } | ||
|
|
||
| public void uploadBdioEntries(BlackDuckRunData blackDuckRunData, UUID bdScanId) throws IntegrationException, IOException { | ||
| public void uploadBdioEntriesForRapidMode(BlackDuckRunData blackDuckRunData, UUID bdScanId) throws IntegrationException, IOException { |
Contributor
There was a problem hiding this comment.
thanks for changing these names, massive w! 👍
bd-samratmuk
approved these changes
Apr 15, 2026
…tructor as it is no longer used.
…tions are tightly coupled with the legacy idea of a waitable code location.
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
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.
Goal: Remove or replace expensive notification API usage in Detect (as per request from perflab) without changing existing behaviour.
Related blackbuck-common PR that must be merged and released first: blackducksoftware/blackduck-common#475. This will be a major version bump as the removal of the now unused "get latest user notification timestamp" API is a breaking change.
Summary of changes:
1. Safe removal of calls to notifications API in places where we do not need it:
► detector and signature (uses BOM status polling in all cases)
► binary (uses BOM status polling, except when server version is too old for multipart upload)
► impact analysis (currently no mechanism for checking the completion status. See HUB-25142)
► iac (never used notification based waiting, noop)
2. For remaining notification use cases, reduce API calls by simply using upload start time as the polling window start.
New behavior:
If and when needed, notifications APIs are used for polling as they were before, only the starting timestamp has changed.
3. Removal of waitAtScanLevel boolean which simply represented if BD sever version exists and it is >=2023.1.1. 2023.1.x has reached end of support.
4. Docs: release note + updating wait property to indicate iac and impact analysis tools are not applicable.
Note on where we still use notification APIs:
In the case of a binary scan against a BD version < 2024.7.0, we use pre-SCASS binary scan with legacy upload mechanism (no multiparty upload possible). In this specific case, we mustWaitAtBomSummaryLevel for completion if detect.wait.for.results is set to TRUE. Though we will no longer make API calls to determine most recent notification, we will still eventually poll the notifications endpoint. In this case, we will see in the logs: