Skip to content

Conversation

@shiki
Copy link
Contributor

@shiki shiki commented Nov 29, 2019

This has the same contents as #10877. The difference is this one is targeting release/13.7.

Testing

Please do the same testing steps in #10877.

Submitter Checklist

  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.
  • If it's feasible, I have added unit tests.

@peril-wordpress-mobile
Copy link

peril-wordpress-mobile bot commented Nov 29, 2019

You can test the changes on this Pull Request by downloading the APK here.

@shiki shiki marked this pull request as ready for review November 29, 2019 21:33
@shiki shiki requested a review from jd-alexander November 29, 2019 21:33
Copy link
Contributor

@jd-alexander jd-alexander left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🚀

@jd-alexander jd-alexander merged commit cf669fd into release/13.7 Nov 29, 2019
@jd-alexander jd-alexander deleted the issue/10872-fix-upload-starter-for-release-13-7 branch November 29, 2019 21:50
ParaskP7 added a commit that referenced this pull request Sep 26, 2022
Warning Messages: "@synchronized annotation is not applicable to suspend
functions and lambdas"

This coroutines warning is suppressed, that is, instead of it being
resolved, since it seems that:
1. Adding the '@synchronized' annotation was done deliberately, and
2. Changing that is a bit complicated as it would need a bit more
thought to properly fix this, using [Mutex] or otherwise.

For more info see:
- Fix crash in UploadStarter on Samsung devices with Android 5 #10878
(Introduced In): https://github.com/wordpress-mobile/WordPress-Android/
pull/10878
- Forbid @synchronized annotation on suspend functions (Kotlin Issue):
https://youtrack.jetbrains.com/issue/KT-27333/
Forbid-Synchronized-annotation-on-suspend-functions
- Coroutines and Java Synchronization Don't Mix (Blog Post:
https://blog.danlew.net/2020/01/28/
coroutines-and-java-synchronization-dont-mix/
@ParaskP7
Copy link
Contributor

👋 @malinajirka !

It's been almost 3 years already, I know... 😅 But, let me ask you this coroutines related question below, just in case you still remember the answer. 🤞

As part of this Compile Warnings PR, that I am currently working on, I was trying to resolve the @Synchronized annotation related warning. To that end, I ended-up suppressing this warning instead, at least until I discuss it with you first (see here). In this commit you will also notice that I added a couple of links as resources to help us figure out how to properly solve this warning:

To that end, and as far as you aware and remember, do you think we could/should resolve this @Synchronized annotation related warning, maybe by using the something like this recommended Mutex solution, or, do you think that we should just ignore that altogether, suppressing it as I did and only touch that piece of logic again, when and if need be in the distant future. Wdyt? 🤔

@malinajirka
Copy link
Contributor

@ParaskP7 I do remember this code and convo relatively well considering how long it has been - time flies :).

  1. I'm wondering how come you pinged me even though I'm not mentioned on this PR at all :D? Just out of curiosity.
  2. We were originally using the solution with a Mutex, but refactored it in this PR because it was crashing on Samsung devices with Android 5. Since we do not support Android 5 anymore, I believe it is safe to revert this change and start using mutex again.
  3. I'd personally vote for fixing this issue, since if the code doesn't work with coroutines it might lead to race conditions which might result in double-uploads of posts and such - these kind of issues might be there without us knowing about them. However, that doesn't mean we shouldn't fix them. Moreover, I believe the fix is relatively simple and the code is tested for most parts.

Let me know if I can provide some further context.

@ParaskP7
Copy link
Contributor

@malinajirka time flies indeed! 🛸

  1. I just annotated this line on AS and it showed your name. Then, I copied the revision number (d5b9948) which pointed to this PR. From the 3 commits included in this PR, I am seeing you being involved in the main first one as well. 🧙
  2. Thank you so much for the extra clarification on that. Yes, I agree, we can revert this change and start using Mutex again, especially since we do not need to support Android 5 anymore (API Level 21). PS: Out current minimum SDK version is the 24 (Android 7).
  3. I am voting on fixing this issue as well. It indeed seems a bit dangerous to have this kind of race conditions sitting there, waiting to bite us when we would least expect it, and even worse, as you said, having them there without us even knowing about them.

Moreover, I believe the fix is relatively simple and the code is tested for most parts.

👍 🌟 🤞

Let me know if I can provide some further context.

Not only you provided all the context I needed, you also did it at the speed of light, thank you for that, so much appreciated! 🙇

FYI: I'll proceed with updating my PR and revert this change to Mutex again. 💯

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants