Updating an existing user that is online throws an error

[lukef]

If you first grab a user record like so:

filter := map[string]interface{}{
    "id": "<user id>",
}
users, usersErr := streamClient.QueryUsers(&stream.QueryOption{
    Filter: filter,
    Limit:  1,
})

Then modify the user and attempt to save it, like ..

streamUser.Image = "<photo url>"
_, streamUpdateErr := streamClient.UpdateUser(streamUser)

It will fail with the following error:

chat-client: HTTP POST https://chat-us-east-1.stream-io-api.com/users?api_key=<secret> status 400 Bad Request: {\"code\":4,\"message\":\"UpdateUsers failed with error: \\\"users[<userid>].online is a reserved field\\\"\",\"exception_fields\":{\"users[<userid>].online\":\"users[<userid>].online is a reserved field\"}

It seems like if that is reserved, it should be omitted?

[ferhatelmas]

@lukef even if error is clear, SDK definitely should help more here.

[lukef]

@ferhatelmas absolutely. The issue, primarily, is that there is no way to strip out anything "reserved" or to know what is actually reserved if you're just trying to update an existing record after fetching it. i.e.:

• Get User
• Update user model
• Re-Save user

It's actually impossible to do this use case btw. It will fail every time (hence this ticket).

In the above scenario, it will contain the entire user record and any attributes / values that may/may not be reserved.

It might be useful to have an update struct to differentiate between a user and what the API requires. e.g.:

type UserUpdateOptions struct {
  // allowed values here
}

This way you can create a set of "safe" options that can be updated.

[ferhatelmas]

@lukef It's clear, not convenient in this flow.

Your suggestion sounds reasonable at first but we already have a partial update and it's in that direction so if a client knows what to (un)set, it's the preferred way to accomplish that.

In the example flow, anything reserved should be filtered automatically or to save some work from SDKs, server can ignore them.

/cc @thesyncim what do you think about ignoring in server side ?