FS-1517 Partial success on fetch prekeys#3108
Conversation
Adding a new version of the list-prekeys routes that can return partial successes, listing qualified users that they weren't able to list.
mdimjasevic
left a comment
There was a problem hiding this comment.
In the tests you've added I'd expect not checking for local users' prekeys, but for remote ones. Let me know if I'm missing something!
…ial-success-on-endpoint-to-fetch-prekeys-foo
|
I've also updated some of the handler names so that the |
|
At first I thought this test failure in Brig is unrelated, but given the involved type, I figure it is related: |
mdimjasevic
left a comment
There was a problem hiding this comment.
I believe there are things that have to be updated in the integration tests. The application code looks good now.
| ( Right $ | ||
| QualifiedUserClientPrekeyMapV4 | ||
| { qualifiedUserClientPrekeys = QualifiedUserClientMap Map.empty, | ||
| failedToList = pure [Qualified uid1 domain] |
There was a problem hiding this comment.
As mentioned above, it seems wrong to me to qualify a local user uid1 with a (fake) remote domain.
…ial-success-on-endpoint-to-fetch-prekeys
The same test still fails in the CI: |
|
Local testing is showing green across the board. Can we re-run the CI tests? |
…ial-success-on-endpoint-to-fetch-prekeys
mdimjasevic
left a comment
There was a problem hiding this comment.
In tests, I didn't get how you can authenticate with a fake remote user. This shouldn't work, but perhaps our test infrastructure is lacking.
I think I mentioned it before, but in the tests I don't see how you test prekey fetching from an unreachable backend. It could be I am missing it so can you please point me to it?
| . paths ["users", "list-prekeys"] | ||
| . contentJson | ||
| . body (RequestBodyLBS $ encode userClients1) | ||
| . zUser (qUnqualified uid2) |
There was a problem hiding this comment.
User uid2 is a remote user. The way Wire is designed is that users/clients always talk directly and exclusively with their own backend, and never with a remote backend. Therefore, given that uid2 is remote, the user shouldn't be making a request to this backend. I'm not sure how this could result in a 200 response as I'd expect a 404 or something like that. Can you please clarify this for me?
| . paths ["users", "list-prekeys"] | ||
| . contentJson | ||
| . body (RequestBodyLBS $ encode userClients2) | ||
| . zUser (qUnqualified uid2) |
Adding a new version of the list-prekeys routes that can return partial successes, listing qualified users that they weren't able to list.
Checklist
changelog.dChanges
I've updates /users/list-prekeys to include a new field, which required the current structure to be moved down into a new key. The bulk of the data has not changed, it just under a new field to support the new
failed_to_listfield that is populated on partial success.New tests added, old tests updated to reflect their max API version, and a new test added that checks for
failed_to_list