fix: extract & pass correct headers & header values to exhort#378
Open
Strum355 wants to merge 2 commits intoguacsec:mainfrom
Open
fix: extract & pass correct headers & header values to exhort#378Strum355 wants to merge 2 commits intoguacsec:mainfrom
Strum355 wants to merge 2 commits intoguacsec:mainfrom
Conversation
Review Summary by QodoFix header names and extraction logic for Trustify backend
WalkthroughsDescription• Updated header names from rhda-* to trust-da-* prefix • Refactored setRhdaHeader() to accept explicit options key parameter • Simplified getTokenHeaders() by removing vendor token loop logic • Updated JSDoc and option names to use TRUSTIFY_DA_* prefix consistently Diagramflowchart LR
A["Header Constants"] -->|Updated prefix| B["trust-da-* headers"]
C["setRhdaHeader Function"] -->|Added optsKey param| D["Direct option lookup"]
E["getTokenHeaders Function"] -->|Removed vendor loop| F["Simplified header setup"]
G["JSDoc & Options"] -->|Renamed to TRUSTIFY_DA_*| H["Consistent naming"]
File Changes1. src/analysis.js
|
Strum355
commented
Feb 10, 2026
Comment on lines
+42
to
+44
| * TRUSTIFY_DA_SOURCE?: string | undefined, | ||
| * TRUSTIFY_DA_TOKEN?: string | undefined, | ||
| * TRUSTIFY_DA_TELEMETRY_ID?: string | undefined, |
Member
Author
There was a problem hiding this comment.
Shouldve been updated at the same time as fabric8-analytics/fabric8-analytics-vscode-extension#848, unfortunately was missed
Code Review by Qodo
✅ 1.
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
src/analysis.js
Outdated
Comment on lines
248
to
254
| function getTokenHeaders(opts = {}) { | ||
| let supportedTokens = ['snyk', 'oss-index'] | ||
| let headers = {} | ||
| supportedTokens.forEach(vendor => { | ||
| let token = getCustom(`TRUSTIFY_DA_${vendor.replace("-", "_").toUpperCase()}_TOKEN`, null, opts); | ||
| if (token) { | ||
| headers[`ex-${vendor}-token`] = token | ||
| } | ||
| let user = getCustom(`TRUSTIFY_DA_${vendor.replace("-", "_").toUpperCase()}_USER`, null, opts); | ||
| if (user) { | ||
| headers[`ex-${vendor}-user`] = user | ||
| } | ||
| }) | ||
| setRhdaHeader(rhdaTokenHeader, headers, opts); | ||
| setRhdaHeader(rhdaSourceHeader, headers, opts); | ||
| setRhdaHeader(rhdaOperationTypeHeader, headers, opts); | ||
| setRhdaHeader(rhdaPackageManagerHeader, headers, opts) | ||
| setRhdaHeader(rhdaTelemetryId, headers, opts); | ||
| setRhdaHeader(rhdaTokenHeader, headers, 'TRUSTIFY_DA_TOKEN', opts); | ||
| setRhdaHeader(rhdaSourceHeader, headers, 'TRUSTIFY_DA_SOURCE', opts); | ||
| setRhdaHeader(rhdaOperationTypeHeader, headers, rhdaOperationTypeHeader.toUpperCase().replaceAll("-", "_"), opts); | ||
| setRhdaHeader(rhdaPackageManagerHeader, headers, rhdaPackageManagerHeader.toUpperCase().replaceAll("-", "_"), opts) | ||
| setRhdaHeader(rhdaTelemetryId, headers, 'TRUSTIFY_DA_TELEMETRY_ID', opts); |
There was a problem hiding this comment.
2. Cli validate-token broken 🐞 Bug ✓ Correctness
Vendor-specific token headers (ex-snyk-token/ex-oss-index-token) are no longer generated, but the CLI still sets TRUSTIFY_DA_<PROVIDER>_TOKEN. This makes the validate-token command (and any flow still using vendor tokens) send no auth header and fail.
Agent Prompt
### Issue description
The PR removed vendor-token header generation, but `src/cli.js` and unit tests still use `TRUSTIFY_DA_<PROVIDER>_TOKEN` and expect `ex-snyk-token` headers. This breaks `validate-token` and any vendor-token-based authentication.
### Issue Context
`getTokenHeaders()` now only reads `TRUSTIFY_DA_TOKEN` and no longer maps `TRUSTIFY_DA_SNYK_TOKEN`/`TRUSTIFY_DA_OSS_INDEX_TOKEN` into request headers.
### Fix Focus Areas
- src/analysis.js[248-255]
- src/cli.js[29-55]
- test/analysis.test.js[114-205]
### Suggested approach
Choose one:
1) **Migrate**: Change CLI validate-token to accept/set `TRUSTIFY_DA_TOKEN` (remove provider arg if no longer needed) and update tests accordingly.
2) **Compatibility**: Add fallback logic so `getTokenHeaders()` still emits `ex-snyk-token`/`ex-oss-index-token` when `TRUSTIFY_DA_SNYK_TOKEN`/`TRUSTIFY_DA_OSS_INDEX_TOKEN` are provided, while also supporting the new `trust-da-token` header.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Collaborator
There was a problem hiding this comment.
the TRUSTIFY_DA__TOKEN is used when we need the backend to authenticate with the Trustify instance whereas the trust-da-token will be used to authenticate against the DA instance when logging is required.
There was a problem hiding this comment.
Question:
the TRUSTIFY_DA__TOKEN is used when we need the backend to authenticate with the Trustify instance whereas the trust-da-token will be used to authenticate against the DA instance when logging is required.
Answer:
This looks like the bot is conflating two different auth concepts in your system (provider-specific Trustify token vs DA “logging” token). You can reduce this type of incorrect remediation suggestion by adding explicit guidance via extra_instructions (for the tools that generate bugfix/code-change suggestions), so the model keeps these tokens separate and doesn’t suggest “migrating everything to TRUSTIFY_DA_TOKEN” unless the PR explicitly changes the auth contract.
Add something like this to your repo’s .pr_agent.toml (or wiki .pr_agent.toml) so it applies consistently:
[pr_code_suggestions]
extra_instructions = """\
When reviewing/auth-related changes:
- Do NOT assume TRUSTIFY_DA_<PROVIDER>_TOKEN and `trust-da-token` are interchangeable.
- Treat TRUSTIFY_DA_<PROVIDER>_TOKEN as the backend->Trustify-instance authentication token.
- Treat `trust-da-token` as the token for authenticating against the DA instance (e.g., for logging).
- If a suggestion involves changing token/env var names or HTTP auth headers, explicitly verify which downstream service is being authenticated to (Trustify vs DA) and keep both flows working unless the PR explicitly removes one.
- Prefer backward-compatible changes (fallbacks) unless the PR explicitly documents a breaking auth change.
"""
[pr_reviewer]
extra_instructions = """\
For auth/token discussions, call out and preserve the distinction between:
(1) backend->Trustify authentication (TRUSTIFY_DA_<PROVIDER>_TOKEN)
(2) DA-instance authentication for logging (`trust-da-token`)
"""If you share which interface you’re using (GitHub App vs GitHub Action vs CLI) and which tool produced the suggestion (/improve vs /review), the guidance can be narrowed to only that tool.
Relevant Sources:
ruromero
requested changes
Feb 10, 2026
Collaborator
ruromero
left a comment
ruromero
left a comment
There was a problem hiding this comment.
I've added some comments on top of the AI review
src/analysis.js
Outdated
Comment on lines
248
to
254
| function getTokenHeaders(opts = {}) { | ||
| let supportedTokens = ['snyk', 'oss-index'] | ||
| let headers = {} | ||
| supportedTokens.forEach(vendor => { | ||
| let token = getCustom(`TRUSTIFY_DA_${vendor.replace("-", "_").toUpperCase()}_TOKEN`, null, opts); | ||
| if (token) { | ||
| headers[`ex-${vendor}-token`] = token | ||
| } | ||
| let user = getCustom(`TRUSTIFY_DA_${vendor.replace("-", "_").toUpperCase()}_USER`, null, opts); | ||
| if (user) { | ||
| headers[`ex-${vendor}-user`] = user | ||
| } | ||
| }) | ||
| setRhdaHeader(rhdaTokenHeader, headers, opts); | ||
| setRhdaHeader(rhdaSourceHeader, headers, opts); | ||
| setRhdaHeader(rhdaOperationTypeHeader, headers, opts); | ||
| setRhdaHeader(rhdaPackageManagerHeader, headers, opts) | ||
| setRhdaHeader(rhdaTelemetryId, headers, opts); | ||
| setRhdaHeader(rhdaTokenHeader, headers, 'TRUSTIFY_DA_TOKEN', opts); | ||
| setRhdaHeader(rhdaSourceHeader, headers, 'TRUSTIFY_DA_SOURCE', opts); | ||
| setRhdaHeader(rhdaOperationTypeHeader, headers, rhdaOperationTypeHeader.toUpperCase().replaceAll("-", "_"), opts); | ||
| setRhdaHeader(rhdaPackageManagerHeader, headers, rhdaPackageManagerHeader.toUpperCase().replaceAll("-", "_"), opts) | ||
| setRhdaHeader(rhdaTelemetryId, headers, 'TRUSTIFY_DA_TELEMETRY_ID', opts); |
Collaborator
There was a problem hiding this comment.
the TRUSTIFY_DA__TOKEN is used when we need the backend to authenticate with the Trustify instance whereas the trust-da-token will be used to authenticate against the DA instance when logging is required.
Strum355
force-pushed
the
nsc/request-headers-fix
branch
from
9c21993 to
17bbce1
Compare
ruromero
approved these changes
Feb 11, 2026
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
2 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.
Description
Based on the changes to the backend here: guacsec/trustify-dependency-analytics#514
Checklist
Additional information
Will need to bump in vscode extension after merge