You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FAILED lib/galaxy_test/selenium/test_history_multi_view.py::TestHistoryMultiView::test_list_list_display - selenium.common.exceptions.TimeoutException: Message: Failed waiting on history item 3 to become visible, visible datasets include [#dataset-f06d708dacad69d8,#dataset-da92407cb46a61f3]. Timeout waiting on CSS selector [.multi-history-panel .content-item[data-hid="3"]] to become visible.
Most of the details are already in #16754 (comment) moving it to its own issue as they are unrelated.
Summary
Now everything is starting to make sense, but still, I have a piece of the puzzle missing in my head...
The "collection loop issue" is caused by this change I made in #16725
I was wrongly assuming the ID of the DCObject (DatasetCollection) was the same ID used to query api/dataset_collections/{id} so I fetched the "collection" from the store to drill down.
These are the values of the variables in the case of the test failure:
itemObject: DCObject
{
"id": "df7a1f0c02a5b08e", <-- This is a DatasetCollection ID"model_class": "DatasetCollection",
"collection_type": "list",
"populated": null,
"element_count": null,
"contents_url": "/api/dataset_collections/df7a1f0c02a5b08e/contents/df7a1f0c02a5b08e", <- ID coincidence..."elements": []
}
The mixed ID df7a1f0c02a5b08e was causing the drill-down collection stack to push always the same HDCA, creating the loop. That could explain why it failed only when more selenium tests were run vs. just running TestHistoryMultiView::test_list_list_display in isolation. There was a higher chance of hitting this mixed ID issue.
The missing part of the puzzle is the actual solution 😅 I need to wrap my head around the different concepts related to collections, HDCA, DCE, DC... but maybe someone more versed in collection internals can help... The previous solution relied on querying the contents_url for drilling down, but I wanted to use the fetcher to get all the typing benefits and make use of the store for caching results.
Any ideas on how to do the correct query here?
Galaxy Version and/or server at which you observed the bug
Galaxy Version: dev
Commit: (run git rev-parse HEAD if you run this Galaxy server)
To Reproduce
Steps to reproduce the behavior:
Create a collection with sub-collections
Try to drill down into the sub-collections by clicking on the UI entry.
Observe that in some situations, the UI doesn't seem to update with the contents of the sub-collection.
Expected behavior
You can view the contents of the sub-collection.
Additional context
In the UI it looks like the drilling down doesn't do anything, but it is actually displaying the same parent collection every time you click on the sub-collection pushing it to the navigation (breadcrumbs) stack.
The text was updated successfully, but these errors were encountered:
Related Selenium test currently failing:
Most of the details are already in #16754 (comment) moving it to its own issue as they are unrelated.
Summary
Now everything is starting to make sense, but still, I have a piece of the puzzle missing in my head...
The "collection loop issue" is caused by this change I made in #16725
galaxy/client/src/components/History/CurrentCollection/CollectionPanel.vue
Line 63 in 2ed0ab0
I was wrongly assuming the ID of the
DCObject
(DatasetCollection) was the same ID used to queryapi/dataset_collections/{id}
so I fetched the "collection" from the store to drill down.These are the values of the variables in the case of the test failure:
itemObject: DCObject
collection: HDCA
The mixed ID
df7a1f0c02a5b08e
was causing the drill-down collection stack to push always the same HDCA, creating the loop. That could explain why it failed only when more selenium tests were run vs. just runningTestHistoryMultiView::test_list_list_display
in isolation. There was a higher chance of hitting this mixed ID issue.The missing part of the puzzle is the actual solution 😅 I need to wrap my head around the different concepts related to collections, HDCA, DCE, DC... but maybe someone more versed in collection internals can help... The previous solution relied on querying the
contents_url
for drilling down, but I wanted to use the fetcher to get all the typing benefits and make use of the store for caching results.Any ideas on how to do the correct query here?
Galaxy Version and/or server at which you observed the bug
Galaxy Version: dev
Commit: (run
git rev-parse HEAD
if you run this Galaxy server)To Reproduce
Steps to reproduce the behavior:
Expected behavior
You can view the contents of the sub-collection.
Additional context
In the UI it looks like the drilling down doesn't do anything, but it is actually displaying the same parent collection every time you click on the sub-collection pushing it to the navigation (breadcrumbs) stack.
The text was updated successfully, but these errors were encountered: