-
Notifications
You must be signed in to change notification settings - Fork 928
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't assume order when testing links to changeset elements #4571
Don't assume order when testing links to changeset elements #4571
Conversation
Good catch. Would it be a better idea for us to sort the elements instead? I've had a brief look at the website, and it would seam reasonable to sort the elements by id and version. That way the order is stable, and also might be helpful for mappers too (e.g I think if I saw nodes 1, 2, 5, ..., 20 on the first page, I'd be surprised to find node 4 mentioned on page 7). I also think the test could be improved. At the moment the test creates 21 items for each type of element, and then checks that the first 20 are visible. But it doesn't check that the 21st item is not visible, and it doesn't check that there are page links to view the next page. I can see what you are doing with the changes that you propose, but I think that leads to a very complex test, in order to handle a situation (lack of sort order) that I don't think is intentional. |
|
Another reasonable order is by modification time, which is what usually happens already. |
I'm sorry I wasn't clear - I was commenting on the original test. I meant that even if we establish a sort order, the test could still benefit from improvements. |
Changeset download sorts elements by (timestamp, version): |
Meanwhile the test keeps failing sometimes https://github.com/openstreetmap/openstreetmap-website/actions/runs/8284476948/job/22677523145?pr=4578 |
I'm with @gravitystorm that this is the wrong fix - aside from the horrendous complexity involved in this fix it's fundamentally wrong to try and do pagination without a fixed order. Without a sort you have no guarantee that the database will use the same order for each page so you may wind up seeing some things twice and not seeing others at all as you move through the pages. |
15 years of wrong pagination 2ed84e2 |
Not needed if #5209 is merged. |
I noticed that one test fails sometimes:
That's probably because I assumed that on the changeset page the elements will be shown in the same order as they were created. But actually they are not sorted, so sometimes the order may be different.
Here I remove the ordering assumption and check the next page for an element that was missing from the first page.