Conversation
| } | ||
|
|
||
| this.loginCallback() | ||
| await this.loginCallback() |
There was a problem hiding this comment.
Good catch. loginCallback is typed as () => Promise<void>, so this await is necessary — the other three call sites (lines 45, 82, 112) already await it. Without it, this.userName = loginParams.username on the next line could execute before the callback completes, causing a race condition.
| } | ||
|
|
||
| if (typeof jsonResponse === 'string') { | ||
| jsonResponse = getValidJson(jsonResponse) |
There was a problem hiding this comment.
This unconditional getValidJson call applies to all server types, not just SAS9. Note that FileUploader.ts (line 106) does the same but guards with else if (this.serverType !== ServerType.Sasjs). For Sasjs, SasjsRequestClient.parseResponse already calls getValidJson, so res.result should already be an object — the typeof === 'string' check protects against that. However, consider whether a Sasjs guard is warranted here for consistency with FileUploader and to avoid double-parsing if the request client ever returns a string.
Also note: getValidJson throws JsonParseArrayError if the parsed JSON is a top-level array (see src/utils/getValidJson.ts:11). Before this PR, non-debug SAS9 string responses passed through as-is. If a SAS9 stored process can return a top-level JSON array, this will now throw where it previously did not. If array responses are not expected from SAS9, this is fine; if they are, this is a behaviour change worth documenting.
| response?.isLoggedIn && response?.userName === userName | ||
| adapter.getSasjsConfig().serverType === ServerType.Sas9 | ||
| ? response?.isLoggedIn | ||
| : response?.isLoggedIn && response?.userName === userName |
There was a problem hiding this comment.
This relaxation is correct: extractUserName in AuthManager.ts (line 286) returns '' for ServerType.Sas9, so the userName assertion can never pass on SAS9. Keeping the isLoggedIn check is the right level of validation for SAS9.
Minor: consider adding a brief comment explaining why the assertion differs for SAS9 (no username extraction), so future readers don't mistake this for incomplete testing.
There was a problem hiding this comment.
Hermes Agent Code Review
Verdict: Approve — with minor notes
Overview
This PR fixes three issues to make sasjs tests pass on SAS9:
-
src/auth/AuthManager.ts— Awaitsthis.loginCallback()at line 144, which was the only un-awaited call site out of four. This is a genuine bug fix —loginCallbackis typed() => Promise<void>, and withoutawait,this.userNameis set on the next line before the callback completes, creating a race condition. -
src/job-execution/WebJobExecutor.ts— AddsgetValidJson()parsing for string responses in the non-debug path. Before this change, non-debug SAS9 string responses passed through raw toappendExtraResponseAttributes, inconsistent withFileUploader.tswhich already parses them. This brings parity. -
sasjs-tests/src/testSuites/Basic.ts— Relaxes the session check assertion for SAS9 to only checkisLoggedIn(notuserName), sinceextractUserNamereturns''for SAS9. Correct.
Issues Found
Minor (no action required to merge):
-
WebJobExecutor.ts:188— ThegetValidJsoncall is unconditional across all server types, whereasFileUploader.tsguards withserverType !== ServerType.Sasjs. Thetypeof === 'string'check mitigates this for Sasjs (sinceSasjsRequestClientpre-parses), but a guard would improve consistency. Additionally,getValidJsonthrowsJsonParseArrayErrorfor top-level JSON arrays — if SAS9 stored processes can return array JSON, this is a new failure mode. Likely acceptable given the intent, but worth being aware of. -
Basic.ts:58— Consider adding a brief comment explaining why the assertion differs for SAS9 (no username extraction), to aid future readers.
Verification
- ✅
npm run build— compiles successfully (webpack, 0 errors) - ✅ Unit tests — 188 passed, 4 failed. The 4 failures are in
RequestClient.spec.ts(TLS certificate tests), pre-existing and unrelated to this PR's changes. - ✅
getValidJsonedge cases verified: empty string →{}, null/undefined → throwsInvalidJsonError, arrays → throwsJsonParseArrayError.
Security
No security concerns. No injection vectors, no secret leakage, no auth bypass.
Reviewed by Hermes Agent (GitHub App)
Issue
closes #688
Checks
No PR (that involves a non-trivial code change) should be merged, unless all items below are confirmed! If an urgent fix is needed - use a tar file.
sasjs-cliunit tests are passing (npm test).sasjs-testsare passing. If you want to run it manually (instructions available here).