chore: do not fetch backend metadata when loading user session - WPB-24411#4513
Conversation
…dataUseCase` - just rethrow errors
| import WireLogging | ||
| import WireNetwork | ||
|
|
||
| open class AuthenticatedSessionFactory { |
There was a problem hiding this comment.
This code is no longer used
There was a problem hiding this comment.
This was dead code
There was a problem hiding this comment.
This was dead code
| } | ||
|
|
||
| // Get new metadata. | ||
| // Otherwise fetch and store new metadata. |
There was a problem hiding this comment.
This work is now only done here if we don't have some existing backend metadata. Fetching the latest now happens elsewhere - in a Worker
Test Results0 tests 0 ✅ 0s ⏱️ Results for commit aa852bd. ♻️ This comment has been updated with latest results. Summary: workflow run #23787807022 |
|
netbe
left a comment
There was a problem hiding this comment.
looks good,
just one question: I am a bit confused about the different systems we have at the moment and to which one is going away vs staying.
Could you clarify usage and future of following?
- RecurringActionService
- Worker
- WorkAgent
| import WireLogging | ||
| import WireNetwork | ||
|
|
||
| open class AuthenticatedSessionFactory { |



Issue
This PR decouples fetching background metadata from loading the user session. The idea behind this effort is to not block the user from launching the app - under bad network conditions the user might wait 1 minute until a network request times out.
Instead this PR introduces a
Workerthat will attempt to fetch the latest background metadata at various intervals and store that metadata on disk. The new metadata will only be used the next time the user session is loaded.This affects the API version used and whether federation is used. In practice I don't think this should be an issue. API versions are generally not deprecated immediately and on the rare occasion of switching from a non federated to federated setup, I believe the behavior is the same as if federation was enabled while the application was already running - we wouldn't get the change until the next app launch. An improvement, not included in this PR could be to have this work also done as a background task.
I did discuss what happens on Android. There the request is also not tied to the loading of the user session. However with their setup I believe when the request is made and changes detected, those changes will take effect immediately. I expect this would be hard to achieve on iOS though.
Testing
Test fetching API version doesn't block user
Test migrating API version
Checklist
[WPB-XXX].