fix(debug): route JES web debug responses on the actual _debug value …

[YuryShkoda]

Issue

Closes #898

Intent

request() calls fail outright on SAS Viya when debug: true is combined with the JES web app execution path (useComputeApi left null/undefined) and runAsTask: true — even though the underlying SAS service completes successfully. The adapter picks the wrong debug-response parser for this configuration, so a valid webout response either throws (Unable to find webout file URL.) or crashes outright, and callers see a failure where there wasn't one.

Fix this so debug: true works correctly for this configuration, and make the fix resilient to the underlying cause changing shape in the future (the _debug=128 value in use today is a workaround for a SAS platform bug that's expected to be reverted once fixed upstream).

Implementation

• Root cause: WebJobExecutor.execute() selected a parser based on config.useComputeApi === null && config.runAsTask === true. But WebJobExecutor is only ever reached (via SASjs.request()) once useComputeApi is already known to be null/undefined — that routing decision happens one layer up. So a caller passing useComputeApi: undefined explicitly failed the strict === null check and fell through to the parser built for the older _debug=131 iframe-URL response format, which doesn't understand the current _debug=128 HTML/Blob format and fails.
• Fix: capture the actual _debug value produced by getRequestParams(config) (the single source of truth for which format the server will send back) and route parsing on that value directly, instead of re-deriving it from runAsTask. This avoids the two staying in sync only by convention — if the _debug=128 workaround is reverted to 131 in the future while runAsTask stays true, parsing still follows the actual value sent.
• Defensive hardening: the older _debug=131 parser (parseSasViyaDebugResponse) now falls back to the same blob/weboutBEGIN extraction used by the newer parser if its iframe-URL pattern isn't found, instead of hard-failing. Extracted the shared blob-matching logic into a new extractWeboutBlob helper used by both parsers.
• Tests (TDD): added WebJobExecutor.debug.spec.ts (previously no test file existed for this class's response parsing at all) reproducing the exact failing configuration, a guard test confirming the non-runAsTask path is untouched, and a regression test that mocks getRequestParams to return _debug: 131 while runAsTask: true — simulating the future-revert scenario — verified to fail under the runAsTask-keyed version of the fix before being treated as a real guard. Extended parseViyaDebugResponse.spec.ts with the new fallback-extraction cases.
• Verified: full suite green (303 tests), npm run build and npm run lint pass.

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.

• Unit tests coverage has been increased and a new threshold is set.
• All sasjs-cli unit tests are passing (npm test).
• (CI Runs this) All sasjs-tests are passing. If you want to run it manually (instructions available here).
• Data Controller builds and is functional on both SAS 9 and Viya

[github-actions]

Coverage report

Total coverage

Status	Category	Percentage	Covered / Total
🟡	Statements	68.22%	2052/3008
🔴	Branches	50.53%	862/1706
🔴	Functions	56.97%	331/581
🟡	Lines	73.52%	3124/4249

Status of coverage: 🟢 - ok, 🟡 - slightly more than threshold, 🔴 - under the threshold

Show new covered files 🌑

Coverage of new files

Status	Filename	Statements	Branches	Functions	Lines
🟢	src/utils/extractWeboutBlob.ts	100%	100%	100%	100%

Status of coverage: 🟢 - ok, 🟡 - slightly more than threshold, 🔴 - under the threshold

Show files with reduced coverage 🔻

Reduced coverage

Status	Filename	Statements	Branches	Functions	Lines
🟢	src/utils/parseViyaLogDebugResponse.ts	90% (-2.31% 🔻)	50% (-25% 🔻)	100%	100%

Status of coverage: 🟢 - ok, 🟡 - slightly more than threshold, 🔴 - under the threshold

Report generated by 🧪jest coverage report action from 715978f