Project duplication

[danwentworthart]

Tool: Carbohydrate Builder

Bug Description: In cases where the downloads page is reached via the options page, if a user hits the back button, the options page load logic creates a new project, but it has the same pUUID as the previous project. This causes subsequent queries on pUUID to find two matches. That is bad.

To Reproduce:

1. Build a sequence that contains a 1-6 linkage somewhere. This ensures you will hit the options page.
2. Select some options and generate some sequences, which redirects you to downloads page.
3. When finished loading, hit the back button in the browser.
4. Return to the Downloads page: Structure never loads. Look in git-ignore-me.error.log and you will find this:

   2022-09-15 11:55:21 AM - cb.views - ERROR - There was a problem loading the project: get() returned more than one CbProject -- it returned 2!
   2022-09-15 11:55:21 AM - cb.views - ERROR - Traceback (most recent call last):
   File "/website/glycam-django/glycamweb/cb/views.py", line 968, in buildRequestedStructures
   project = CbProject.CbProject.objects.get(pUUID=pUUID)
   File "/usr/local/lib/python3.9/site-packages/django/db/models/manager.py", line 85, in manager_method
   return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/usr/local/lib/python3.9/site-packages/django/db/models/query.py", line 439, in get
   raise self.model.MultipleObjectsReturned(
   project.models.CbProject.CbProject.MultipleObjectsReturned: get() returned more than one CbProject -- it returned 2!

Expected behavior Prior to creating a new project, query existing projects for a matching pUUID. That is generated by gems, and gets added to the Django db after the fact. If it already exists, just use it.

[cexum]

Once this is fixed create a Selenium test.

[danwentworthart]

I believe this issue relates to Oliver's observations about project-bleed when users try to work with multiple tabs open.

[gitoliver]

Is this fixed now?

[danwentworthart]

This is progressed forward, but not fixed. I was able to eliminate project duplication, but our features are in the way. The fact that we want the download page to serve two contexts:

1. Requesting the Conformers on first visit,
2. Loading previously built projects

means that the logic I wrote is interpreting the old build pUUID in the db as an indication that it was previously built. But, I am currently seeing if there is a way I can detect this pattern and get the behavior we want.

If my proposal of combining the Options/Downloads page is ever considered worth doing, that would resolve this. A browser back button click would go back to the index page of whichever tool was used, which I think is more appropriate.

[danwentworthart]

I did fix this. I had to make some decisions to do this.

1. I had to turn off all Django caching for the index, options, and download page. Otherwise you load the page without running javascript and strange states occur.
2. Now, when the options page is visited, it checks to see if a build_pUUID has been registered with the user project. If so, it clears it. This is necessary because if this exists, the download page will treat the project as previously completed.
3. This means that going back to the options page will overwrite any previous build_pUUID, severing that output from this user's project. Think of it as a soft overwrite, even though the data dir would be untouched. It just breaks the link to this user project. Reuse of previously built stuff would not be impacted at all.

To the user, this might mean they build only one of 3 conformers on the first pass, go back to Options and ask for all 3. After that, the downloads page and the project detail page would always represent the most recent state, in this case all 3 conformers would be present.

This is fixed locally, not distributed yet.