Unable to toggle Share My Location to off

[aksonov]

Error in tinyrobot

Error in MainActivity
GraphQL friendShareUpdate error: {"__typename":"FriendUpdatePayload","messages":[{"__typename":"ValidationMessage","code":"unknown","field":"contactId","message":"must be a friend"}],"result":null,"successful":false}

View on Bugsnag

Stacktrace

third-party/wocky-client/src/transport/Transport.ts:1355 - 

View full stacktrace

Created by Miranda via Bugsnag

[mstidham]

Pixel taps on user netflix avatar from the header to display card. Pixel then taps to expand card. Pixel taps on Share My Location toggle and it doesn't do anything and this bugsnag was generated.

[aksonov]

Could you give bypass numbers to reproduce?

[bengtan]

Looking in loggly:

Account pixel (a350fb43-33b0-40b4-ac76-175cc2090379) on Staging sent/received the following request/response to/from the server:

// Sent at 2020-02-28T19:04:58.468888Z
["9","39","__absinthe__:control","doc",{"query":"mutation friendShareUpdate($input: FriendShareUpdateInput!) {\n friendShareUpdate(input: $input) {\n messages {\n code\n field\n message\n __typename\n }\n successful\n result {\n user {\n id\n handle\n __typename\n }\n createdAt\n shareConfig {\n nearbyDistance\n nearbyCooldown\n __typename\n }\n shareType\n __typename\n }\n __typename\n }\n}\n","variables":{"input":{"userId":"227ec704-3eba-4da7-9cf7-4ca9bd4af723","location":{"device":"396efc7323f85be0","lon":-99.21898899475383,"lat":36.42102913971508,"accuracy":65,"activity":"still","activityConfidence":100},"shareType":"DISABLED"}}}]

// Received at 2020-02-28T19:04:58.472712Z
["9","39","__absinthe__:control","phx_reply",{"response":{"data":{"friendShareUpdate":{"__typename":"FriendUpdatePayload","messages":[{"__typename":"ValidationMessage","code":"unknown","field":"contactId","message":"must be a friend"}],"result":null,"successful":false}}},"status":"ok"}]

Similar packets also happened at:

// 2020-02-28T19:05:01.277216Z
["9","41", ...

// 2020-02-28T19:05:01.281311Z
["9","41", ...

// 2020-02-28T19:05:02.649476Z
["9","42", ...

// 2020-02-28T19:05:02.653299Z
["9","42", ...

// 2020-02-28T19:05:15.860608Z
["9","46", ...

// 2020-02-28T19:05:15.864480Z
["9","46", ...

// 2020-02-28T19:05:17.075432Z
["9","47", ...

// 2020-02-28T19:05:17.079294Z
["9","47", ...

// 2020-02-28T19:16:54.167304Z
["9","28", ...

// 2020-02-28T19:16:54.171079Z
["9","28", ...

The other account id in the packets (227ec704-3eba-4da7-9cf7-4ca9bd4af723) is user netflix.

I don't know, at the time of these packets, whether pixel and netflix were friends or not. (Does @mstidham remember, maybe?)

What I do find interesting is that ... the validation message complains about field contactId but no such field appears in the request. (Any thoughts about contactId, @bernardd or @toland?)

[mstidham]

They should have been friends or the user wouldn't have been on the header.

[toland]

What I do find interesting is that ... the validation message complains about field contactId but no such field appears in the request. (Any thoughts about contactId, @bernardd or @toland?)

This is an artifact of how we do field validation. The validation happens at the database level and the database field is called contact_id (automatically translated to contactId by the GQL layer). We normally try to keep the API fields and database fields named the same so that everything matches up, but during the recent overhauls to contacts and sharing things got a bit out of sync.

The actual GQL field is called userId.

[bengtan]

Given that this bugsnag only happened once and it was almost 2 weeks ago, I'm gonna de-prioritise until/unless it happens again.