fix(job): wire onTokensRefreshed into startComputeJob (#1461)

[sasjs-dev]

Resolves #1461

Summary

sasjs job execute (and sasjs flow execute) didn't pass an onTokensRefreshed callback to SASjs.startComputeJob, unlike executeScript in run.ts, executeCode.ts, and executeDeployScriptSasViya.ts. For password-grant users with no client/secret fallback, a stale refresh token forces a manual re-login after long-running compute jobs.

This PR wires persistTokensRefreshedByAdapter(target) as the onTokensRefreshed callback in both call sites:

• src/commands/job/internal/execute/viya.ts (executeJobViya)
• src/commands/flow/internal/executeFlow.ts (executeFlow)

The adapter side (threading onTokensRefreshed through startComputeJob to executeComputeJob) is already in place in @sasjs/adapter 4.18.0; this completes the CLI wiring.

Tests

Added a new test case in src/commands/job/spec/execute.spec.ts verifying that persistTokensRefreshedByAdapter(target) is called with the target and that the resulting function is passed as the last argument to startComputeJob. Also updated the two existing test cases to assert expect.any(Function) for the new callback argument.

[4gl-reviewer]

This call does not compile against the currently published adapter. CI fails at the build step with:

src/commands/job/internal/execute/viya.ts(117,7): error TS2554: Expected 2-9 arguments, but got 10.

The published @sasjs/adapter@4.18.0 startComputeJob signature ends at verboseMode?: VerboseMode (9 params) and has no onTokensRefreshed parameter yet — that parameter is added by adapter PR #899, which is not yet merged/published.

This PR is therefore blocked on #899 being merged and released (the ^4.18.0 range will then resolve to the new version). Until then CI is red on both Linux and Windows runners. Consider keeping this PR in draft, or landing it only after #899 is published.

[4gl-reviewer]

Same TS2554 compile error here:

src/commands/flow/internal/executeFlow.ts(71,11): error TS2554: Expected 2-9 arguments, but got 10.

Blocked on adapter #899 for the same reason as viya.ts. The argument order itself is correct (verified against the PR #899 signature: …, variables, verboseMode, onTokensRefreshed), so once #899 is published this will compile — but it cannot merge in its current state.

[4gl-reviewer]

Hermes Agent Code Review

Verdict: REQUEST_CHANGES — the PR cannot compile against the currently published adapter; CI is red on both Linux and Windows. Blocked on adapter PR #899.

Critical

• TypeScript build failure (blocking). Both startComputeJob call sites pass 10 arguments, but the published @sasjs/adapter@4.18.0 accepts at most 9 (it has no onTokensRefreshed parameter). CI output:

  src/commands/flow/internal/executeFlow.ts(71,11): error TS2554: Expected 2-9 arguments, but got 10.
  src/commands/job/internal/execute/viya.ts(117,7): error TS2554: Expected 2-9 arguments, but got 10.
  

  The onTokensRefreshed parameter is introduced by adapter PR #899, which is not yet merged or published. This PR must wait for #899 to be merged, released, and for the CLI lockfile to pick up the new version (^4.18.0 will resolve to it). I verified the published 4.18.0 .d.ts directly: startComputeJob(..., variables?, verboseMode?) — no 10th param.

Warnings

• None beyond the above.

Suggestions

• Once #899 lands, the argument order here is correct (I verified it against the #899 signature: …, variables, verboseMode, onTokensRefreshed). To avoid future off-by-one risk on these long positional calls, consider tracking the adapter's move to an options object if/when it happens.
• The new test mocks configUtils.persistTokensRefreshedByAdapter to return jest.fn() and asserts the last startComputeJob arg isDefined() and typeof === 'function'. Consider also asserting the returned function is the same instance the spy returned (e.g. capture it: const cb = jest.fn(); spy.mockImplementation(() => cb) then expect(callArgs[10]).toBe(cb)), which would prove the wiring end-to-end rather than just that a function was passed.

Looks Good

• persistTokensRefreshedByAdapter(target) in utils/config.ts is well-implemented: it reuses the same sanitizeEnvValue + saveTokens path as getAuthConfig, so rotated Viya refresh tokens are persisted consistently and client/secret are preserved in .env.{target}. Good doc comment explaining the single-use/rotating token rationale.
• Both call sites (viya.ts, executeFlow.ts) thread the callback with the same argument order, and the two existing tests were updated consistently to expect expect.any(Function) as the final arg.
• The new dedicated test verifies persistTokensRefreshedByAdapter is called with target and that a function reaches startComputeJob.

Reviewed by Hermes Agent (GitHub App)

[github-actions]

Coverage report

Total coverage

Status	Category	Percentage	Covered / Total
🟡	Statements	75.3%	3472/4611
🟡	Branches	62.86%	1415/2251
🟡	Functions	75.03%	700/933
🟢	Lines	83.86%	8855/10559

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/commands/compile/compileSingleFile.ts	95.83% (-2.08% 🔻)	84% (-4% 🔻)	100%	100%

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

Report generated by 🧪jest coverage report action from 36902e3

resolved by main's @sasjs/adapter bump to 4.19.0