No way to re-fetch expired avatars.

Bug #1153896 reported by Robert Bruce Park
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Friends
Fix Released
High
Robert Bruce Park

Bug Description

So, this is a bug that I've suspected for a long time but wasn't able to confirm until I started seeing missing avatars in the qml frontend.

What's happening is that friends caches avatar URLs as new messages are published, and then some weeks later deletes the cached avatar images, but because we only store the cached URI rather than the original URL, we have no way to retrieve expired avatars that are still necessary. Essentially, if you're browsing through your stream, and you see a message that is older than ~3 weeks, and that particular person has not made any new messages since 3 weeks ago, then their avatar is lost from the cache, and we have no way of repopulating the cache because the original avatar URL is lost.

There are two possible solutions to this:

1. Stop deleting avatars from the cache entirely. We would need to add some new logic that redownloads old-ish cached avatars occaisionally, but at no point would we ever delete an avatar, leaving the frontends broken without avatars.

2. stop storing the cached avatar URI in the deemodel, but instead store the original public avatar URL instead, and then provide a public API method to fetch the cached avatar URI for our frontends to use. This would give us the information we need to actually be able to redownload avatars in the event of a cache miss after the expiry logic has deleted an avatar that we need.

Option 2 is how old Gwibber used to do it, but then I introduced the current behavior in the name of simplification without realizing the bug I was introducing.

Any thoughts, Ken?

Related branches

Revision history for this message
Ken VanDine (ken-vandine) wrote :

I think I prefer option 2.

Revision history for this message
Robert Bruce Park (robru) wrote :

One thought -- option 2 requires new API, which we would need an FFe for... but option 1 we could just do without changing any API. the only change would be in the Avatar class where it decides to give you the local URI back, it would just check the mtime quickly to decide whether or not to redownload. all that API already exists, just a matter of invoking it more often.

So basically I think option 1 is the only chance we have of including the fix in raring... does that change your mind at all?

Changed in friends:
status: New → Triaged
importance: Undecided → High
assignee: Ken VanDine (ken-vandine) → Robert Bruce Park (robru)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:friends at revision 172, scheduled for release in friends, milestone Unknown

Changed in friends:
status: Triaged → Fix Committed
Changed in friends:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.