Btw the sorting on the server is always as intended whether there is a new article or not. So definetely newly added articles are dated properly, this seems to be an issue in the Android app.

Also this issue arised after I upgraded the Wallabag to 2.3.2 I think I was using something like 2.2 before.

Hi,

I managed to reproduce the issue when migrating from one wallabag instance to another.
Wallabag server v.2.4.2, Android app v.2.4.2.

Steps to reproduce:

• Deploy a wallabag server with sqlite database, create a user, add some articles (I had around 700), export articles using wallabag:export command
• Deploy another wallabag server with Mariadb database, create a user, import articles using wallabag:import command, add some new articles, connect the Android app to this server and check the order of articles

Observations:
wallabag_entry table on the first server:

| id | created_at |
| 1  | date1      |
| 2  | date2      |
| 3  | date3      |

Both id and created_at values are in ascending order.

wallabag_entry table on the second server immediately after import:

| id | created_at |
| 1  | date3      |
| 2  | date2      |
| 3  | date1      |

id values are in ascending order but created_at values are in descending order. Most probably this is due to the fact that the export file contains newest articles first so they are imported in that order.

wallabag_entry table on the second server after adding some new articles:

| id | created_at |
| 1  | date3      |
| 2  | date2      |
| 3  | date1      |
| 4  | date4      |

It feels like article ordering in the Android app is based on the id value. Manually updating ids to make both id and created_at values in ascending order fixes the problem.

It feels like article ordering in the Android app is based on the id value.

That is indeed the case. Thanks for pointing out the situation where it doesn't work.