Skip to content

fix(web): stamp the target's appLoc into the app streamed to a SASjs target - #1555

Merged
allanbowe merged 2 commits into
mainfrom
fix/sasjs-apploc-override
Nov 5, 2026
Merged

allanbowe merged 2 commits into
mainfrom
fix/sasjs-apploc-override

Conversation

@sasjs-dev

@sasjs-dev sasjs-dev Bot commented Nov 5, 2026

Copy link
Copy Markdown
Contributor

For a SASjs Server target the streamed app is copied verbatim, so the <sasjs> tag keeps whatever appLoc the frontend was built with. Served from AppStream the app gets no appLoc from its URL either - so a deployment to any appLoc but the frontend's default has it calling services on the default one.

Reproduced on sas.4gl.io

Deployed a Data Controller estate to /Public/app/dc477 and clicked BROWSE on the deploy screen. With the browser instrumented, the request went to the default appLoc:

POST https://sas.4gl.io/SASjsApi/stp/execute/?_program=/Public/app/dc/services/admin/makedata

and came back with that appLoc's refusal, while /Public/app/dc477 had never been touched. The deployed file confirmed it:

/Public/app/dc477/services/web/index.html -> apploc="/Public/app/dc"

The change

createWebAppServices (the compile step that materialises the streamed app) already parses the index and rewrites the tag for Viya and SAS9 via updateSasjsTag. The SASjs branch now does the same, on the copy it has just made:

await copy(webSourcePathFull, destinationPath)

const copiedIndex = path.join(destinationPath, 'index.html')
const indexHtml = new jsdom.JSDOM(await readFile(copiedIndex))
const sasjsTags = getSasjsTags(indexHtml)

if (sasjsTags.length) {
  updateSasjsTag(sasjsTags[0], target)
  await fs.promises.writeFile(copiedIndex, indexHtml.serialize())
}

updateSasjsTag sets appLoc and serverType from the target, so the value deployed and the value the app calls cannot disagree.

Verification

  • npx jest src/commands/web: 36 passing across the seven suites; the new case builds a web folder with appLoc="/Public/app/default", streams it to a SASjs target at /Public/app/AnotherLoc and asserts the copy carries the target's appLoc. It fails if the stamping is removed (checked).
  • Prettier clean.
  • End to end: with this build deployed to /Public/app/dc477, the served services/web/index.html carries apploc="/Public/app/dc477" and BROWSE on that deployment lists folders (DC620298, DC620385, DC627259) instead of calling the default appLoc.

Related but separate: #1554 (the worker script's own URL) - that one is about a stale worker serving a previous build's runtime.

…target

For a SASjs Server target the web app is copied to services/<streamWebFolder>
verbatim, so the <sasjs> tag keeps whatever appLoc the frontend was built with -
"/Public/app/dc" in the project this was found on. Served from AppStream the app
gets no appLoc from its URL, so a deployment to any other appLoc had it calling
services on the default one. On a fresh deployment to /Public/app/dc477 the
deploy screen's BROWSE posted to /Public/app/dc/services/admin/makedata, which
is configured, and answered "DIRLIST and WRITECHECK are only available until DC
is configured" while the appLoc it was deployed to had never been touched.

Viya and SAS9 already rewrite the tag (updateSasjsTag over the parsed HTML); the
SASjs branch now does the same on the copied index.html.

Verified by deploying the DC estate to /Public/app/dc477 with this CLI: the
deployed services/web/index.html carries apploc="/Public/app/dc477", and BROWSE
on that deployment lists folders instead of calling the default appLoc.
@github-actions

github-actions Bot commented Nov 5, 2026

Copy link
Copy Markdown

Coverage ratchet

Compared against the baseline published for the base commit bb30198.

Metric Base Head Delta
statements 83.7% 83.76% +0.06 improved
branches 74.39% 74.4% +0.01 unchanged
functions 82.25% 82.25% 0 unchanged
lines 84.24% 84.3% +0.06 improved

No metric is below the base.

@allanbowe
allanbowe merged commit c1a3226 into main Nov 5, 2026
10 checks passed
@allanbowe
allanbowe deleted the fix/sasjs-apploc-override branch November 5, 2026 18:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant