Skip to content

Conversation

jschaul
Copy link
Member

@jschaul jschaul commented Aug 30, 2021

  • Servantify POST /connections
  • Remove the message field in connection requests, as it has been long deprecated. Some clients may still send it (as it was a mandatory field), but it was never visible at UI level in the past years, so we can remove it.
  • fix an old TODO to make the 256 length check using the Range type, rather than doing it implicitly in the json parser.

The main changeset to types is in libs/wire-api/src/Wire/API/Connection.hs

Some golden tests have been removed as they are no longer relevant.

Checklist

  • The PR Title explains the impact of the change.
  • The PR description provides context as to why the change should occur and what the code contributes to that effect. This could also be a link to a JIRA ticket or a Github issue, if there is one.
  • Section Unreleased of CHANGELOG-draft.md contains the following bits of information:
    • A line with the title and number of the PR in one or more suitable sub-sections.

@jschaul jschaul changed the title [WIP] servantify existing connections endpoints [skip CI] [WIP] servantify existing connections endpoints Sep 2, 2021
@jschaul jschaul changed the title [WIP] servantify existing connections endpoints Servantify existing connections endpoints Sep 2, 2021
@jschaul jschaul changed the title Servantify existing connections endpoints Servantify one existing connections endpoint Sep 2, 2021
@jschaul jschaul marked this pull request as ready for review September 2, 2021 15:00
@jschaul jschaul requested review from akshaymankar, pcapriotti and mdimjasevic and removed request for akshaymankar September 7, 2021 18:44
Copy link
Contributor

@pcapriotti pcapriotti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good.

I would suggest a minor improvement, possibly in a separate PR: now that you have nicely abstracted out this pattern of "existed200/created201", it would be useful to also abstract out the corresponding MultiVerb response list, so that the association between the two responses and the status code is fixed and users cannot get it wrong.

For example, we can add a type to the Util module like:

type ResponsesForExistedCreated eDesc cDesc a = '[
  Respond 200 eDesc a,
  Respond 201 cDesc a ]

and use that as part of the MultiVerb type in the routes that use the pattern.

More suggestions below.

Copy link
Contributor

@mdimjasevic mdimjasevic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left some comments inlined.

Overall, this looks good, though I wish more things were reflected in types given the move to Servant.

crName :: Text,
-- | Initial message
crMessage :: Message
-- FUTUREWORK investigate: shouldn't this name be optional? Do we use this name actually anywhere?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just guessing now, but does a connection name ever make it to a one-to-one conversation title?

Clients have a logic related to conversation titles (e.g., in checking if a group conversation in a team is logically one-to-one conversation).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just guessing now, but does a connection name ever make it to a one-to-one conversation title?

I'm not sure, I didn't take the time to look more deeply into how this is used and what clients send and receive and what they do with it. That's why there is a FUTUREWORK here. A potential refactor that removes this can be done in a subsequent PR.

P.object "ConnectionRequest" $
ConnectionRequest
<$> crUser P..= P.fieldWithDocModifier "user" (P.description ?~ "user ID of the user to request a connection with") P.schema
<*> crName P..= P.fieldWithDocModifier "name" (P.description ?~ "Name of the (pending) conversation being initiated (1 - 256) characters)") P.schema
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not too familiar with connection names and conversation names/titles, but see my previous comment if a connection name is really promoted to a one-to-one conversation title.

improve noIdentity error message
ConnectionResult -> ResponseForExistedCreated
link to docs in FUTUREWORK comment about cassandra migrations
add futurework about 'Connect' event.
remove redundant golden tests.
@jschaul
Copy link
Member Author

jschaul commented Sep 8, 2021

I tried to address all your review comments now.

Copy link
Contributor

@pcapriotti pcapriotti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! 🚀

@jschaul jschaul changed the title Servantify one existing connections endpoint Servantify POST /connections endpoint; remove deprecated 'message' field Sep 8, 2021
@jschaul jschaul merged commit c0f1880 into develop Sep 8, 2021
@jschaul jschaul deleted the servantify-connections-endpoint branch September 8, 2021 17:14
This was referenced Sep 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants