History list doesn't load all of your histories sometimes

[ahmedhamidawan]

The HistoryScrollList component doesn't load all of your histories. For instance, on usegalaxy.org /api/histories/count returns 25 for me, but the historyStore is only able to load 24/25 histories:

https://github.com/galaxyproject/galaxy/assets/78516064/9be00df4-ea62-4dfd-a804-84a94f4e3ddc

Galaxy Version and/or server at which you observed the bug Galaxy Version: 24.0.1.dev0

Expected behavior All 25 histories load, or maybe the backend is returning an incorrect count?

[itisAliRH]

It happens by creating histories using API too.

[davelopez]

Can you check how many histories you have in your local DB for that user and try to determine which one is the one that is not being serialized?

If we identify the missing history, maybe we can tell the difference between listing and counting.

[ahmedhamidawan]

When reproducing this, I found that the complete list of histories returned by api/histories is equal to api/histories/count.✅ However, I suspect that in historyStore.setHistories, for a list of say, 10 histories, we only end up pushing 8 (or lesser than 10) to storedHistories sometimes. Unfortunately, before I could investigate which histories were messing this up, I ended up modifying a history, and that changed the order of histories (sorted by update_time) and "fixed" the loading and I couldn't reproduce this any further... 😞

[davelopez]

Maybe @itisAliRH can reproduce it using the API. Can you try @itisAliRH?

[itisAliRH]

@davelopez @ahmedhamidawan I reproduced the case and recorded it:

https://github.com/galaxyproject/galaxy/assets/8046843/a73a86c9-1998-4315-b577-58a79ac8f619

As you can see in the video, the Switch to history list is not showing the right count until search for a history or refresh the page.

[davelopez]

@itisAliRH, if I follow this correctly, I think this is expected. We are not polling for new histories from the server that are created out of band (and I don't think we should add another continuous poll :thinking:) That is why if you have 19 histories and create a new one (without using the client) you will still see 19, but if you search and query the count it will update to 20 and load the missing one (if it does get hit by the filter) as this is a server-side search.

I'm not completely sure this is the same thing @ahmedhamidawan was reporting but maybe it can be improved in the client by loading summary histories again if we detect the count changed. In any case, it looks to me like the backend is consistent in returning the count and the list of histories for a particular query. We just don't have a mechanism in the client to detect when new histories were created out of band. This probably can be improved.