Precise error message password change

[shashankiitbhu]

Description (required)

Fixes #5522

What changes did you make and why?
Made changes in UploadWorker making the user go to LoginActivity if the password is changed in their current session (which made their current session Invalid), and will display a Persistent Message to the user of what they need to do on Login Page.

Tests performed (required)

Tested 4.2.1-debug-main on Xiaomi 11 Lite NE with API level 33

Screenshots (for UI changes only)

[domdomegg]

As per comments.

[sivaraam]

Thanks for working on this @shashankiitbhu and thanks for the feedback @domdomegg and @whym 🙂 !

I could see what this PR is a achieving is a better state than what we have now. But is it not too late to throw this at the user after they've entered all their details?

Could we not do it as soon as they open the app? Doing it on each open might be a bit costly, may be we could cache the result and re-check once in a few hours?

Or if that sounds too complex, may be just check the validity right when the upload is initiated via the UI? May be asynchronously to rnsure we don't block user's flow? Any thoughts? 🤔

[shashankiitbhu]

@sivaraam

1. If we do it every time the user opens the app then it'll be too expensive

2. If we do it let's say every few hours then there would remain a possibility that the user encounters this same issue when they change their password during that period (Hence we need to handle that case anyway, as we are doing in this PR), we can implement this and also have the changes the I made in this PR currently so that there is no cases where user does not get a clear message after upload failure.

So my proposed solution is:
-> Make the check when a user opens the app and re-check once in a few hours
-> Also keep these changes to handle the above case (2)

This way we are making fewer network requests and ensuring that there are no cases where the user does not get a clear message after upload failure.

Please Let me know what you think about this solution

[whym]

@sivaraam:
I like your idea of checking it earlier than the last step of the uploading process. Do you want to create a new issue for that? If I understand it correctly, the two options are not exclusive.

When tokens are invalidated, it's done on the server side, and we don't know when it will happen. There is a chance that it will happen during the upload process (and the user can take time to choose categories and other options). So I don't think we have to choose between the two timings of checking - I think we want to do both.

EDIT: I copy pasted the wrong user name at the top earlier, sorry.

[shashankiitbhu]

@whym as we have already discussed and as you said we can go with approach 1 here - https://github.com/commons-app/apps-android-commons/issues/5522#issuecomment-1942891133, I am already working on my other 2 PRs for this issue ( or should I create separate issues for those PRs?)

[shashankiitbhu]

@nicolas-raoul Can you please Review and Merge this PR so that I have a clear indication to similarly solve for the other 2 cases as discussed in #5522 (comment) and eventually close the issue #5522 , as it's been open for a while and it's quite crucial bug

[whym]

From my perspective, this looks already okay to merge. I think we can incorporate @sivaraam's idea above in future iterations.

[shashankiitbhu]

@whym Great, then I'll add the other two PRs for the other two scenarios soon and get this issue fixed

[shashankiitbhu]

@nicolas-raoul @RitikaPahwa4444 Please Review & Merge this PR so that I can make the other two PRs

[shashankiitbhu]

@nicolas-raoul @RitikaPahwa4444 @sivaraam can you please review and merge it, thanks

[sivaraam]

Sorry for the delay here. I just had one comment about curbing the redundant code. Kindly check the same 🙂

[sivaraam]

@sivaraam: I like your idea of checking it earlier than the last step of the uploading process. Do you want to create a new issue for that? If I understand it correctly, the two options are not exclusive.

When tokens are invalidated, it's done on the server side, and we don't know when it will happen. There is a chance that it will happen during the upload process (and the user can take time to choose categories and other options). So I don't think we have to choose between the two timings of checking - I think we want to do both.

I agree with you on this. We would indeed need both of those options. On a side note, it would be worth exploring how the Wikipedia app handles this. They do have a logout method similar to ours. It would be interesting to figure out when and where they call the same.

[shashankiitbhu]

@sivaraam Made Required Changes , Please Review and Merge, thanks

[sivaraam]

Kindly take care of the below comments.

[shashankiitbhu]

@sivaraam Made the changes

[sivaraam]

Thanks for the quick turnaround! Here are few comments to help improve the changes. Do take a look 🙂

[shashankiitbhu]

@sivaraam Made the required changes, Please Review and Merge, thanks

[sivaraam]

I left some comments regarding the JavaDoc. Kindly check them.

Also, I seem to get the following crash from time to time when the app logs me out due to token invalidation:

android.database.sqlite.SQLiteException: no such table: workspec (code 1 SQLITE_ERROR): , while compiling: SELECT output FROM workspec WHERE id IN
             (SELECT prerequisite_id FROM dependency WHERE work_spec_id=?)
        at android.database.sqlite.SQLiteConnection.nativePrepareStatement(Native Method)
        at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:1053)
        at android.database.sqlite.SQLiteConnection.prepare(SQLiteConnection.java:660)
        at android.database.sqlite.SQLiteSession.prepare(SQLiteSession.java:590)
        at android.database.sqlite.SQLiteProgram.<init>(SQLiteProgram.java:62)
        at android.database.sqlite.SQLiteQuery.<init>(SQLiteQuery.java:37)
        at android.database.sqlite.SQLiteDirectCursorDriver.query(SQLiteDirectCursorDriver.java:46)
        at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1546)
        at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1521)
        at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.query(FrameworkSQLiteDatabase.kt:156)
        at androidx.room.RoomDatabase.query(RoomDatabase.kt:481)
        at androidx.room.util.DBUtil.query(DBUtil.kt:75)
        at androidx.work.impl.model.WorkSpecDao_Impl.getInputsFromPrerequisites(WorkSpecDao_Impl.java:1552)
        at androidx.work.impl.WorkerWrapper.runWorker(WorkerWrapper.java:223)
        at androidx.work.impl.WorkerWrapper.run(WorkerWrapper.java:145)
        at androidx.work.impl.utils.SerialExecutorImpl$Task.run(SerialExecutorImpl.java:96)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
        at java.lang.Thread.run(Thread.java:1012)

It seems similar to this issue reported here. Am I the only one facing this? Or is it generally reproducible? If it is common, any idea on what's causing this issue?

[shashankiitbhu]

Also, I seem to get the following crash from time to time when the app logs me out due to token invalidation:

I have not faced this Issue yet so I am not sure if that is related to this PR

[shashankiitbhu]

@sivaraam made the changes suggested, let me know if something else is required, Please Review and Merge, thanks

[sivaraam]

The JavaDocs could still use some improvements. Kindly check the comments.

[sivaraam]

The purpose of the ctx is not specified clearly. Kindly clarify the same.

[sivaraam]

This seems unresolved yet.

[shashankiitbhu]

@sivaraam Made Some changes , Please Review , thanks

[sivaraam]

Just left 2 comments. Kindly check. Rest of the changes look fine 👍

[sivaraam]

This seems unresolved yet.

[shashankiitbhu]

@sivaraam Made the changes, Please Review

[sivaraam]

Thank you for your contribution @shashankiitbhu 🙂