DatasetFSprovider fetchDataset() - fix behavior with non-existent datasets and members

[benjamin-t-santos]

Proposed changes

There are currently issues for extenders with fetching MVS resources on-demand using the v3 file system. I outline them in this issue: #3252.

The proposed changes are:

• Fix how dataset/member names are parsed before fetching them from remote
• Look at the items in the API response to ensure that the requested resource actually exists, rather than just checking if the API call is completed successfully
• Use allMembers when fetching a member vs. dataSet for datasets

In the issue, Trae raised concerns about opened files in Zowe Explorer being impacted when the extension reloads or restarts - I do not see any issues with these new changes. The opened files are fetched and displayed if they are available on the host. If they were deleted via some other source, the editor will display a "The editor could not be opened because the file was not found" message, which seems appropriate.

Release Notes

Milestone: #3252

Changelog:

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Enhancement (non-breaking change which adds or improves functionality)
• Breaking change (a change that would cause existing functionality to not work as expected)
• Documentation (Markdown, README updates)
• Other (please specify above in "Proposed changes" section)

Checklist

General

• I have read the CONTRIBUTOR GUIDANCE wiki
• All PR dependencies have been merged and published (if applicable)
• A GIF or screenshot is included in the PR for visual changes
• The pre-publish command has been executed:
  • v2 and below: yarn workspace vscode-extension-for-zowe vscode:prepublish
  • v3: pnpm --filter vscode-extension-for-zowe vscode:prepublish

Code coverage

• There is coverage for the code that I have added
• I have added new test cases and they are passing
• I have manually tested the changes

Deployment

• I have added developer documentation (if applicable)
• Documentation should be added to Zowe Docs
  • If you're an outside contributor, please post in the #zowe-doc Slack channel to coordinate documentation.
  • Otherwise, please check with the rest of the squad about any needed documentation before merging.
• These changes may need ported to the appropriate branches (list here):

Further comments

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.05%. Comparing base (d6ddf68) to head (c2c439f).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3255      +/-   ##
==========================================
+ Coverage   93.02%   93.05%   +0.02%     
==========================================
  Files         113      113              
  Lines       11720    11729       +9     
  Branches     2523     2640     +117     
==========================================
+ Hits        10903    10914      +11     
+ Misses        815      813       -2     
  Partials        2        2              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[benjamin-t-santos]

I do recognize this is a core part of the code for the ZE data sets view. Take all the time needed for review

[traeok]

These changes look good to me, I tested opening multiple data sets, both through the tree view and a virtual workspace - contents were still fetched as expected.

I noticed that the changelog entry was in the FTP extension - can you please move this to the zowe-explorer/CHANGELOG.md file?

I'll approve this as soon as that's resolved. Thanks for the fix!

[benjamin-t-santos]

These changes look good to me, I tested opening multiple data sets, both through the tree view and a virtual workspace - contents were still fetched as expected.

I noticed that the changelog entry was in the FTP extension - can you please move this to the zowe-explorer/CHANGELOG.md file?

I'll approve this as soon as that's resolved. Thanks for the fix!

Oops 🤦‍♂️ I moved it.

[zFernand0]

Changes LGTM! 😋

Left a couple of suggestions, but I think it'd good as-is 🙏

[zFernand0]

Suggested change

	if (resp.success && resp.apiResponse?.items?.length > 0) {
	const dsorg: string = resp.apiResponse?.items?.[0]?.dsorg;
	entryIsDir = pdsMember ? false : dsorg?.startsWith("PO") ?? false;
	if (resp.success && resp.apiResponse?.items?.length > 0) {
	entryIsDir = resp.apiResponse.items.[0].dsorg.startsWith("PO");

[zFernand0]

Suggested change

	const memberName = path.parse(uriPath[1]).name;
	if (
	resp.success &&
	resp.apiResponse?.items?.length > 0 &&
	resp.apiResponse.items.find((respItem) => respItem.member === memberName)
	) {
	entryIsDir = false;
	} else {
	throw vscode.FileSystemError.FileNotFound(uri);
	entryIsDir = false;
	const memberName = path.parse(uriPath[1]).name;
	if (
	!resp.success ||
	resp.apiResponse?.items == null ||
	!resp.apiResponse.items.find((respItem) => respItem.member === memberName)
	) {
	throw vscode.FileSystemError.FileNotFound(uri);

[benjamin-t-santos]

Incorporated @zFernand0's feedback

[zFernand0]

Thanks for considering the logic changes. Sorry for being picky 😋

LGTM! 😋

[t1m0thyj]

Thanks @benjamin-t-santos for your contribution!

Looks pretty good, left just one comment about a potential optimization.

[t1m0thyj]

For members I don't believe attributes are needed since we only look at names on the API response. Listing without attributes may make the fetch operation more efficient:

Suggested change

	const resp = await ZoweExplorerApiRegister.getMvsApi(uriInfo.profile).allMembers(uriPath[0], {
	attributes: true,
	});
	const resp = await ZoweExplorerApiRegister.getMvsApi(uriInfo.profile).allMembers(uriPath[0]);

[t1m0thyj]

LGTM, thanks @benjamin-t-santos!