[timgerstel]

Proposed changes

This PR fixes a regression where switching between editor tabs did not update the displayed content -- the editor kept showing the previously active buffer even though a different tab was selected. It reproduces deterministically in a fresh session, for both USS files and MVS datasets/members.

Root cause: In setMonacoModel (monaco.service.ts), models are created and looked up via monaco.Uri.parse(model.uri) (a change introduced to give the reference/label provider a proper Uri with a defined fsPath). However, fileDuplicateChecker() was left comparing the raw generateUri() string against model.uri.toString(). Because Monaco registers models under their parsed Uri.toString() (which can differ from the raw string), the duplicate check returned false for a buffer that was already open. setMonacoModel then took the "not a duplicate" branch and called editorCore.createModel(...) with a URI that already existed, which makes Monaco throw "Cannot add model because it already exists". That exception aborted the observable chain before editor.setModel(newModel) ran, so the editor stayed attached to the previous model -- hence the stale content on tab switch.

Fix: fileDuplicateChecker() now normalizes the incoming URI the same way models are created/looked up (monaco.Uri.parse(uri).toString()) before comparing. The already-open buffer is correctly detected, getModel(...) returns the existing model, and setModel(...) runs -- so the buffer switches as expected.

This PR addresses Issue: [Link to Github issue within https://github.com/zowe/zlux/issues if any]

This PR depends upon the following PRs: N/A

Type of change

• Bug fix (non-breaking change which fixes an issue)

PR Checklist

• If the changes in this PR are meant for the next release / mainline, this PR targets the "staging" branch.
• My code follows the style guidelines of this project (see: Contributing guideline)
• I have commented my code, particularly in hard-to-understand areas
• New and existing unit tests pass locally with my changes
• Relevant update to CHANGELOG.md
• My changes generate no new warnings

Testing

1. Build the editor: cd zlux-editor/webClient && npm run build -- compiles cleanly with no new warnings.
2. In a fresh editor session, open two or more USS files and click between their tabs -- confirm the editor content updates to match the selected tab each time.
3. Repeat with datasets / PDS members (including names with special characters such as (MEMBER)), confirming content switches correctly.
4. Mix USS and MVS tabs and switch back and forth; open, close, and reopen a file, then switch tabs -- content should always reflect the active tab.
5. Regression check for the original AT-TLS change: confirm Go-to-Definition / Find-All-References still resolve (the fsPath-related behavior that prompted the monaco.Uri.parse change is unaffected).

Further comments

The underlying issue is an inconsistency introduced when model creation/lookup switched from raw strings to parsed monaco.Uri objects without updating the duplicate check. Normalizing in fileDuplicateChecker is the minimal, low-risk fix and keeps a single source of truth for URI comparison. A slightly larger alternative would be to drop fileDuplicateChecker entirely and rely on editorCore.getModel(monaco.Uri.parse(model.uri)) directly (returning the existing model if found, else createModel), which removes the redundant model-list scan; I kept the smaller change to minimize blast radius, but I'm happy to refactor to that form if maintainers prefer. No automated test was added since the editor lacks a Monaco integration harness; if desired, a unit test around fileDuplicateChecker asserting that a raw generateUri() string matches an existing parsed-Uri model would lock in the fix.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Martin-Zeithaml]

In my opinion, the comment is a bit too long, though the change itself is straightforward.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud