onProfileUpdated listener not responding to events fired by extenders

[benjamin-t-santos]

Describe the bug
The ZoweVsCodeExtension in the zowe-explorer-api package provides an onProfileUpdatedEmitter that can be fired. The SharedInitclass in Zowe Explorer listens for this event to sync up the profile nodes after a profile is modified.

The issue I am seeing is that the listener registered on line 164 in SharedInit is not responding to the event emitter firing in ZoweVsCodeExtension.updateCredentials().

To reproduce:

1. Configure your zowe.team.config.json file with autoStore: false, secure credentials disabled
2. Extender imports zowe-explorer-api and performs an action that calls ZoweVsCodeExtension.updateCredentials()
3. User enters valid credentials for the profile
4. User uses the same profile in one of the Zowe Explorer views to view data sets, USS files, or jobs

Expected behavior

The profile node Zowe Explorer view should have been updated with the credentials, and the user can use the profile node without entering credentials.

Actual behavior:
User is prompted for credentials again when node of same profile is used

I set up a small sample on a branch in this repo: https://github.com/benjamin-t-santos/zowe-explorer-testing/tree/onprofileupdated-issues

I will add that listening for the onProfileUpdated event as an extender works - if I use the profile node to trigger the update credentials prompt, the ZoweVsCodeExtension.onProfileUpdated() listener we register in our extension detects the event. It's the other direction (firing event as extender) that does not seem to work.

Desktop (please complete the following information):

• OS: Mac OS Sonoma 14.6.1
• Zowe Explorer Version: v3.1.2 for both ZE and ZE API
• (Optional) Zowe CLI Version:
• (Optional) Do you have secure credentials enabled? Disabled
• (Optional) Are you using a custom credential manager? No

Additional context

[github-actions]

Thank you for creating a bug report.
We will investigate the bug and evaluate its impact on the product.
If you haven't already, please ensure you have provided steps to reproduce the bug and as much context as possible.

[traeok]

Recently, I addressed the issue mentioned in the steps to reproduce in #3524:

1. Configure your zowe.team.config.json file with autoStore: false, secure credentials disabled
   ...(rest of steps)

The profile node Zowe Explorer view should have been updated with the credentials, and the user can use the profile node without > entering credentials.

Actual behavior:
User is prompted for credentials again when node of same profile is used

However, these changes were made after v3.1.2 and will be released with v3.2.0. I'll run some manual tests to verify that this particular scenario (developer updating credentials) is resolved with those changes in place.

As for the onProfileUpdated event - I'm wondering if this would be considered a request for enhancement, as the event was initially designed (and implemented) to only propagate updates to extenders, rather than letting extenders propagate updates to us. We fire the event after the profile in our cache has been updated so that extenders know a change has been made. Not to suggest that this isn't a desirable feature, but it just wasn't an intended use case based on the initial design.

[benjamin-t-santos]

@traeok I tried building with azowe-explorer-api packaged from the main branch, and I still experience the issue I outlined above.
I made the first step in my "Steps to reproduce" disabling the secure credential manager and setting autoStore : false so Zowe Explorer would have to cache and read creds from memory. From my perspective, the issue is that even though the ProfilesCache is updated via ZoweVsCodeExtension.updateCredentials(), the profile nodes do not automatically pick up the latest changes to the cache.

Understood that the onProfileUpdated event was not intended to be used that way. I see on #3524 , you made the following change:

The refresh button beside each tree view (Data Sets, Unix System Services, Jobs) no longer reloads profiles. Now, when the refresh button is clicked, it refreshes all profile nodes in the tree and ensures that they are using the latest profile information from the cache.
This change seems to enable a workaround for this issue. I just tested the following:

1. Configure your zowe.team.config.json file with autoStore: false, secure credentials disabled
2. Extender imports zowe-explorer-api and performs an action that calls ZoweVsCodeExtension.updateCredentials()
3. Click the refresh button, and use then use the profile in that view

In this case, the profile does pick up the credentials from memory.

These refresh buttons are fire commands that extenders can also execute, so a workaround would be executing the refresh command for each view after the credentials are updated extender-side.

It would be nice to support letting extenders propagate updates to Zowe Explorer, but this workaround should suffice in the meantime (unless there are other side effects from refreshing each view that I am unaware of).

[traeok]

Ah, I see - this makes more sense to me now. Because the event is fired but the listener is never called, the profile is not updated on the profile nodes for each tree provider to reflect the change, causing the desync until you run the refresh commands.

It's a bit strange that this event is not firing as it fires when we update credentials, but definitely something we can look into, and not quite 1:1 to what that PR was trying to solve. Thanks for clarifying on that.

[benjamin-t-santos]

Exactly. Execution reaches the line in ZoweVsCodeExtension.updateCredentials() where the emitter is fired (and the cache is correctly updated before that), but the listener I mentioned before does not detect the event, causing the profile node to be out of sync with the cache. Thanks for taking a look.

[traeok]

I took a look at your sample and identified the issue, its very subtle:

const zeApi = ZoweVsCodeExtension.getZoweExplorerApi("2.0.0-SNAPSHOT");
const defaultProfile = zeApi
  .getExplorerExtenderApi()
  .getProfilesCache()
  .getDefaultProfile();
ZoweVsCodeExtension.updateCredentials({ profile: defaultProfile }, zeApi);

While this works to update the profiles cache, it does not fire the same event as the one that the listener is subscribed to, as the ZoweVsCodeExtension import is not the same instance that Zowe Explorer itself uses. It's a separate instance pulled in from a dependency.

Essentially, the static methods are tied to the class object itself, but the ZoweVsCodeExtension that Zowe Explorer imports is not the same object as the one you are calling functions on, due to the nature of how its imported from node_modules. Therefore, its firing the event on your import of the class and not the event tied to the import that Zowe Explorer uses.

Ultimately, if we expose the ZoweVsCodeExtension import directly through a function on the API register class - getCoreUtilities - that provides that exact instance to extenders, it would allow you to subscribe to the event that we added a listener to, and also resolves other concerns regarding accessibility to credential-related functions. But this would be breaking to expect extenders to update their code to not use the static class when accessing the event, so maybe there's a better way to approach this...

Maybe we can revisit how we're currently exposing our APIs for v4 so that their usage is a bit more streamlined.

[traeok]

But this would be breaking to expect extenders to update their code to not use the static class when accessing the event, so maybe there's a better way to approach this...

Unintended foreshadowing? I thought of a fix that's quite straightforward, and is working with the VSIX of your sample + the latest API changes on the branch refactor/move-on-profileupdated. Still working on resolving some tests.

This should work for now, we can refactor this class or move the event in v4 😋

[benjamin-t-santos]

I tested your PR with our use case and it worked!