conda-incubator / conda-store-ui

conda-store-ui is a frontend for conda-store powered by react
https://conda-incubator.github.io/conda-store-ui/
BSD 3-Clause "New" or "Revised" License
13 stars 18 forks source link

BUG - Environments with same name (in different namespace) are not fetched/displayed properly #261

Closed dharhas closed 11 months ago

dharhas commented 1 year ago

Not sure how reproducible this is since I don't know what is causing it.

Edit to include Chris' message:

We think we have the issue. It has to do with the UI not distinguishing between namespacea/env and namespaceb/env with how it stores state.

In our JATIC Govcloud Nebari deployment, one of the environments does not load. It just shows spinning icons, in all sections except description:

image

If I switch to working environment i.e. dashboard

image

and switch back to the jatic-toolbox environment, then the description from the dashboard environment is shown.

image

kcpevey commented 1 year ago

I think there may be two separate things here:

  1. I've seen that if you're viewing the env as its building, it doesn't always refresh the page when its done.
  2. I've never the Builds section just spin like that.

This env did build, the logs are available and it made it all the way to the final "to activate this env type conda activate..."

dharhas commented 1 year ago

Its happening on the global/examples env on nebari.quansight.dev which is an existing env that is not being built.

costrouc commented 1 year ago

We think we have the issue. It has to do with the UI not distinguishing between namespacea/env and namespaceb/env with how it stores state.

trallard commented 1 year ago

@kcpevey and I discussed this yesterday. I am adding a few notes that will help whoever tackles this.

🔍 This issue arises when the user has two environments with the same name in different namespaces. When a user tries and view any of those environments, conda-store fails to do so as it seems it is not making the differentiation of namespace-1 and namespace-2 and somehow only looking at environment names.

No error is thrown (not sure what the response is), and in any case, conda-store should always be namespace and environment aware. Since I am unfamiliar with "how conda-store stores state" and why this would lead to the issue above (to me this from an API POV looks like we should be looking for unique URIs and validating at that point).

costrouc commented 1 year ago

Since I am unfamiliar with "how conda-store stores state" and why this would lead to the issue above (to me this from an API POV looks like we should be looking for unique URIs and validating at that point).

I think this is entirely a frontend ui issue. Conda-store always needs namespace/environment-name when performing an action.

For detail on how conda store stores state there is a database diagram https://conda.store/en/latest/contributing.html#model. With a high and low level view.

trallard commented 1 year ago

Regardless of it being frontend only* - there is a miss on identifying the namespace to which each environment belongs, because this happens only when you have multiple envs with the same name. It is basically ignoring the principle that environments or builds exist always and only within a namespace.

How envs are retrieved and shown should follow that principle, the endpoints and data entries are there already. Ultimately both the backend and fronted should be aware of this organisational model and workflows should be designed with both composition (bringing different components together) and separation (where does the ownership/scope of a given component or workflow ends) in mind and that is not happening.

This issue is then not a projection (fetch and display or workflow representation through the interface) but a composition problem, the workflow to retrieve, handle, manage and present data is what is probably not well designed or robust enough. The state (data) and store are defined by the API and database model. That is what I was pointing at when I said I did not know why/how the data/state store would be the culprit when the workflow is what is not working as expected.

*I would not call this a frontend UI only issue if the problem is a composition or workflow one, this sounds more like a system/workflow design issue than a UI (user interface) one.

pierrotsmnrd commented 1 year ago

I have tried to reproduce this, but cannot. I have 3 envs with the same name in 3 different namespaces, and each of them show up as expected.

kcpevey commented 12 months ago

@kcpevey needs to reproduce

kcpevey commented 11 months ago

I've confirmed that I can't reproduce on 2023.9.2. Yay for free fixes! 🎉