-
Notifications
You must be signed in to change notification settings - Fork 333
Fs 897 partial success for list users #3117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fs 897 partial success for list users #3117
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general this looks good, but I wonder if you could reuse the existing handler. I'm not 100% sure myself so I'd like to hear what you think.
services/brig/src/Brig/API/Public.hs
Outdated
-- Similar to listUsersByIdsOrHandles, except that it allows partial successes | ||
-- using a new return type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that the new field is optional. If that is so, then its addition makes the response backwards-compatible. I understand that the new endpoint will not throw for unavailable remote backends, but cannot you bake this into the existing handler? The old endpoint versions wouldn't fail anymore, and they might end up providing an additional field in response, but clients should ignore that field by contract because the field wasn't there when Swaggers for the client API versions were finalised.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It isn't backwards compatible because it introduces a new layer of structure to the response. Previously it was a top level list with nowhere to add a second list, now it is an object containing at least one list, and optionally a second.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, right, it's not backwards compatible in terms of JSON. Nevertheless, I believe the handler can be generalised and reused for both endpoint versions. Or at least factoring out the common bits would be good to have.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated these functions to pull out the common bits
There's this integration test failing in CI:
|
I've updated that test, setting the API version that it should be using. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does this one and the other two testObject_ListUsersById_user_?.json
tests come from? I can't find corresponding Haskell values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The haskell values are in module Test.Wire.API.Golden.Manual.ListUsersById.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry, but I can't find Haskell values testObject_ListUsersById_user_1
, testObject_ListUsersById_user_2
nor testObject_ListUsersById_user_3
in that module nor in any other module. Note the _user
part in the names.
…cess-for-list-users
…cess-for-list-users
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I'd swap the test functions name, but otherwise good to go!
@@ -791,6 +795,73 @@ testMultipleUsers brig = do | |||
field :: FromJSON a => Key -> Value -> Maybe a | |||
field f u = u ^? key f >>= maybeFromJSON | |||
|
|||
testMultipleUsersV3 :: Opt.Opts -> Brig -> Http () |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this one be called testMultipleUsers
(as it uses the latest API version, namely v4) and the other one testMultipleUsersV3
(as it uses the old v3)?
Checklist
changelog.d
Changes
Adding a new V3 version of the /list-users route that allows for partial success when querying federated servers.