fix: exception when executing multiple fetches of the same avatar [WPB-9640]

[saleniuk]

WPB-9640 [Android] FileNotFoundException crash resampleImageAndCopyToTempPath

---

PR Submission Checklist for internal contributors

• The PR Title

  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

• The PR Description

  • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

---

What's new in this PR?

Issues

Sometimes there is a FileNotFoundException when fetching assets.

Causes (Optional)

This exception happens when the app needs to fetch the same image multiple times - coil library (which the app uses to fetch, cache and show images) makes separate requests for each image composable and our logic for downloading image involves storing this image in the temporary cache file, so if we have 2 requests at the same time, one can edit or remove this file and then second can get this FileNotFoundException.

So this happens when for instance we have multiple messages from some user (there have to be minimum 2 avatars of that user on the screen, so not grouped messages) and this user changes avatar so the app needs to fetch and update these avatars. Sometimes, when at least two the same requests happen to be executed at the same time, this exception can occur, so not always, but it’s also visible on the screen because not all avatars of this user are visible, some of them are successful but others are broken because other request already removed a temporary file.

Solutions

The easiest solution would be to make different cache file names for each request so that each one has its own temporary file instead of having one temporary image per specific user avatar, but this way the app still makes multiple requests when only one is required.

Solution from this PR works by creating a mutex map, where a mutex is created and locked for a given key, so that multiple executions for a given key will never be executed at the same time but sequentially one by one. This is needed when the app needs to make a request to download updated avatar so that it won't make multiple requests unnecessary, but only the first execution which locks the mutex will make a request and store the avatar in a file and then other executions will run after that one by one so making another requests won't be needed anymore because the avatar is already available in a file. Also, when there is already avatar downloaded and stored in the file, then thanks to the mutex this file won't be accessed by multiple executions at the same time.

MutexMap creates a mutex associated with a key and locks it so that there's only one execution going for a given key at a given time. When the lock for the given key is executed for the first time, it will create a new entry in the map and lock the mutex. When another lock is executed for the same key while it's locked, it will increase the count and lock the mutex so that it'll wait and execute after the first execution unlocks the mutex. The count is there to keep the mutex in the map as long as it's needed. After the last unlock, the mutex is removed from the map.

Testing

How to Test

• login as user A
• open a conversation with some user B
• make sure that you have at least two non-grouped messages from that user B so that you can see his avatar circle next to message multiple times on the screen
• change the avatar of that other user B
• open profile of user B on your device being logged as user A
• wait until the updated avatar is loaded
• go back to conversation screen
• wait until avatars are loaded
• all avatars should be visible without any exception

Attachments (Optional)

Attachments like images, videos, etc. (drag and drop in the text box)

Before	After
fetch_avatar_multiple_times_issue.mp4	fetch_avatar_multiple_times_fix.mp4

User Michaltest546_2 changed the avatar, when opening his profile the app fetches new data of that user and realises that there is new avatar so after going back to conversation screen it tries to fetch this avatar, but there are 4 elements that should show this avatar so it wants to fetch it 4 times - on the video "before" it actually makes 4 requests at the same time, some of them are successful but others are broken because other request already removed a temporary file. On the video "after" it only makes one request and all other executions wait until it's fetched and can access it from the local file.

---

PR Post Submission Checklist for internal contributors (Optional)

• Wire's Github Workflow has automatically linked the PR to a JIRA issue

---

PR Post Merge Checklist for internal contributors

• If any soft of configuration variable was introduced by this PR, it has been added to the relevant documents and the CI jobs have been updated.

---

References

1. https://sparkbox.com/foundry/semantic_commit_messages
2. https://github.com/wireapp/.github#usage
3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.

[sonarcloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[github-actions]

Built wire-android-staging-release-pr-3101.apk is available for download

[github-actions]

Built wire-android-dev-debug-pr-3101.apk is available for download

[AndroidBob]

Build 5312 succeeded.

The build produced the following APK's:

• com.wire.android-v4.8.0-9941708-staging-compat.apk