On first class open column sorting is always descending

[404-html]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest versions of Parse Server and Parse Dashboard.

Issue Description

Steps to reproduce

1. Go to data browser;
2. Browse any class;
3. Apply ascending sorting on any column;
4. Switch to different class;
5. Go back to the previous class;

Actual Outcome

Sorting seems to be descending.

Expected Outcome

Sorting should be ascending.

Environment

Dashboard

• Parse Dashboard version: 4.0.0-beta.1
• Browser (Safari, Chrome, Firefox, Edge, etc.): Chrome
• Browser version: 97.0.4692.71

Server

• Parse Server version: 4.10.4
• Operating system: Linux
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): Google Cloud

Database

• System (MongoDB or Postgres): MongoDB
• Database version: 4.4.11
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): MongoDB Atlas

Logs

Nothing gets logged in browser' dev tools.

[parse-github-assistant]

Thanks for opening this issue!

• 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

[404-html]

Problem still exists on recent 4.0.0-BETA.2.

[mtrezza]

@visualfanatic Would you mind taking a look at this too? It also seems to be related to the changes in context. If that is in fact the case, I think we would need a more thorough review of #1948 to see whether there may be a conceptual issue with the change, or maybe a different pattern that should be applied to more places in that PR.

[damianstasik]

I checked 4.0.0-alpha.4 which was released before the context changes and it seems like data browser behaves the same. Could you confirm that @404-html?

[404-html]

Thanks for checking @visualfanatic, and I can confirm that problem also exists on 4.0.0-alpha.4 version.
I ran git bisect and it pointed following commit: 52c315a
Some of the logic could be indeed asynchronous, which looks kind of strange. Any idea @visualfanatic?

[damianstasik]

@404-html this one should fix the issue: #2016

[AshishBarvaliya]

@mtrezza Unable to reproduce the issue with the latest versions, indicating that the fix has already been implemented. Can you please verify this and proceed with closing the issue?

[mtrezza]

Thanks for pointing this out, I assume that #2016 has indeed fixed the issue then.