Outbox type: Make `sender_id` required; add optional `stream_id`. #4667

chrisbobbe · 2021-04-16T02:03:29Z

Finish most of #3998! 🎉

Make sender_id required, since the change that added it as optional has been out in a release for a while
Add stream_id, as optional, so the process starts again: once that's been out for a few weeks, we should make that required, and that'll finish off Add sender_id and stream_id properties to Outbox #3998.

Also start type-checking another test file.

WesleyAC

LGTM, except for either tracking or actually fixing the exponential-spread warning.

Thanks for doing this! Having the stream_id in Outbox I think will let us get rid of stream_name in the actionsheet code, which I'm excited about :)

WesleyAC · 2021-04-20T14:58:15Z

src/__tests__/lib/exampleData.js

@@ -444,6 +444,9 @@ export const makeOutboxMessage = (data: $Shape<$Diff<Outbox, {| id: mixed |}>>):
  const outputTimestamp = timestamp ?? makeTime() / 1000;
  return deepFreeze({
    ...outboxMessageBase,
+    /* $FlowFixMe[exponential-spread] - Yeah, we should probably deal


Can you make a ticket to track this, or do it in this PR?

I guess it's not a huge deal, since this is just a problem with typechecking performance, not runtime performance, but it does seem like something we should fix.

chrisbobbe · 2021-04-20T22:09:55Z

Thanks for the review! Revision pushed.

For the Flow error, it seemed sufficient to tweak the type of outboxMessageBase to be based on OutboxBase rather than Outbox. So I did that and changed its jsdoc accordingly.

WesleyAC · 2021-04-29T09:01:42Z

This looks good to me, feel free to merge after you fix the conflict :)

This provides some helpful context; it also this helps make it clear that (in 3ab6a51) we were adding a `browser` property that didn't exist before, rather than changing the value of an existing `browser` property.

As v27.157 has been out for well over a few weeks. And write a migration to strip any outbox messages that don't have it, as noted we should in a1fad7c's TODOs and in zulip#3998.

Now that we've made it required, as it has been on `Message`. Also remove a heading that we probably wished we could have removed in 34bf18b; the `SubsetProperties` of `Message` makes the meaning quite clear.

Only `RenderedMessageDescriptor`, not `RenderedTimeDescriptor`, has an `.isBrief` property. As written, it looks like these tests already fail when `.isBrief` is missing (the `expect` would receive `undefined` instead of a boolean), so this change just makes the expectation more explicit, and will let this code pass type-checking, which we'll start doing soon.

From a search of `sender_email` in all JS files, I didn't see any other obvious places we could take advantage of `sender_id`. Part of zulip#3998.

Like we did with `PmMessage` and `StreamMessage` in zulip#4506. We don't actually make `PmOutbox` any different from `StreamOutbox` in this commit; that'll come later.

…`es. To reinforce the point in the section header: """ (Only stream messages for now. Feel free to add PMs, if you need them.) """ We don't need to handle PMs yet, but this'll hopefully make it clearer how to do so when the time comes.

Much like we did for `sender_id` in a1fad7c. Once a release that has this commit has been out for a few weeks, we should write a migration to strip `StreamOutbox` messages that don't have `stream_id`, and make `stream_id` required. Part of zulip#3998.

chrisbobbe · 2021-05-10T18:34:19Z

This looks good to me, feel free to merge after you fix the conflict :)

Thanks for the review! Done; I also added a commit at the beginning to put a quick comment on migration 28.

gnprice

Thanks @chrisbobbe and @WesleyAC ! Glad to have this taken care of.

I've just pushed the following commits following up on these changes:
6fe63e3 outbox types: Mark PmOutbox and StreamOutbox as read-only.
8171f2d outbox types [nfc]: Fix TODO comment on adding stream_id.
606591b outbox types [nfc]: Add TODO comments on PmOutbox vs. StreamOutbox.

One is trivial. The others are comment-only changes, corresponding to the comments below -- take a look.

I've also drafted up a fix for one of these, completing the distinction between PmOutbox and StreamOutbox. Branch here:
master...gnprice:dev-outbox-types
but it needs some cleaning-up before merge, and it's late here now and I should go to bed 🙂

gnprice · 2021-05-24T06:10:16Z

src/types.js

  ...SubsetProperties<
+    // Could use `MessageBase` here, but Flow would complain anyway if
+    // we tried to put something that's not in `MessageBase` below.
    Message,


Hmm, this doesn't seem to be true 🙂 In fact, several of these aren't on MessageBase -- they're just on both PmMessage and StreamMessage, separately. If I change this to say MessageBase, Flow gives errors here about those as one would hope:

Cannot instantiate SubsetProperties because property display_recipient is missing in MessageBase [1] in the first argument. [prop-missing] … Cannot instantiate SubsetProperties because property subject is missing in MessageBase [1] in the first argument. [prop-missing] … Cannot instantiate SubsetProperties because property type is missing in MessageBase [1] in the first argument. [prop-missing]

The consequence of putting them here is that they each get broken down into unions separately: so type: 'stream' | 'private' and display_recipient: string | $ReadOnlyArray<PmRecipientUser>, but losing the information that a type of 'stream' means a display_recipient that's a string, and so on.

Of course that's the way it already was before this change, when we didn't have PmOutbox and StreamOutbox at all. So that's why no existing code gives a type error because of this loss of information. But it means that if e.g. streamNameOfStreamMessage were to try to rely on the PmOutbox / StreamOutbox distinction -- by dropping its invariant call where it checks that display_recipient is indeed a string -- it would get a type error, because that distinction isn't yet functioning.

gnprice · 2021-05-24T07:06:13Z

src/types.js

+  // TODO(#3764): Make stream_id required.  Needs a migration to drop
+  //   StreamOutbox values that lack it; that'll be fine once the
+  //   release that adds it has been out for a few weeks. (Also drop


There's another key step missing before we can do this: we need to start actually populating this property in the values we create for state.outbox 😉 See a1fad7c for comparison.

chrisbobbe · 2021-05-24T14:14:23Z

Thanks for catching those things, @gnprice! Please let me know if you'd like me to take over master...gnprice:dev-outbox-types; otherwise I'll take a look when you make it into a PR. 🙂

Compare a1fad7c, which did the same for the sender_id property. We actually did part of this a few months ago, in fce3e8b in zulip#4667. That commit added it to the type, but we hadn't yet taken the step of supplying this property in any actual Outbox values. Also add back to a TODO comment a bit that got dropped in 8171f2d.

Compare a1fad7c, which did the same for the sender_id property. We actually did part of this a few months ago, in fce3e8b in zulip#4667. That commit added it to the type, but we hadn't yet taken the step of supplying this property in any actual Outbox values. Also add back to a TODO comment a bit that got dropped in 8171f2d. This makes zulip#3998 mostly complete: the remaining steps will be to get a release with this change out, wait a few weeks, then make `stream_id` required with a migration to drop `Outbox` values that lack it, just as we did for `sender_id` before. Issue: zulip#3998

This property is required (since 60847c9 / #4667, earlier this year), so we can rely on it to simplify away this workaround. This workaround was in fact the original prompt that caused me to notice we didn't have sender_id (or stream_id) on Outbox, and file #3968 (comment)

We started supplying this property in 0c251bf / #5000. That went out to users a few weeks ago, in v17.171 which rolled out 2021-09-23, so by this point the bulk of our users have upgraded to that version. Now we mark the property as required, and drop any old outbox messages that lack it in the unlikely case that there are any. This completes #3998 because we've already done the same thing for `sender_id`, in a1fad7c / #4304 and then 60847c9 / #4667. Fixes: #3998

This property is required (since 60847c9 / zulip#4667, earlier this year), so we can rely on it to simplify away this workaround. This workaround was in fact the original prompt that caused me to notice we didn't have sender_id (or stream_id) on Outbox, and file zulip#3968 (comment)

We started supplying this property in 0c251bf / zulip#5000. That went out to users a few weeks ago, in v17.171 which rolled out 2021-09-23, so by this point the bulk of our users have upgraded to that version. Now we mark the property as required, and drop any old outbox messages that lack it in the unlikely case that there are any. This completes zulip#3998 because we've already done the same thing for `sender_id`, in a1fad7c / zulip#4304 and then 60847c9 / zulip#4667. Fixes: zulip#3998

chrisbobbe requested review from gnprice and WesleyAC April 16, 2021 02:03

chrisbobbe mentioned this pull request Apr 16, 2021

Add sender_id and stream_id properties to Outbox #3998

Closed

WesleyAC approved these changes Apr 20, 2021

View reviewed changes

chrisbobbe force-pushed the pr-outbox-sender-stream-ids branch 2 times, most recently from c2cd382 to 9aeef9a Compare April 20, 2021 22:07

chrisbobbe added 9 commits May 10, 2021 14:29

migrations [nfc]: Comment on what migration 28 was for.

74ae528

This provides some helpful context; it also this helps make it clear that (in 3ab6a51) we were adding a `browser` property that didn't exist before, rather than changing the value of an existing `browser` property.

types: Make sender_id on Outbox required.

60847c9

As v27.157 has been out for well over a few weeks. And write a migration to strip any outbox messages that don't have it, as noted we should in a1fad7c's TODOs and in zulip#3998.

types [nfc]: Put sender_id along with its friends.

d1e504e

Now that we've made it required, as it has been on `Message`. Also remove a heading that we probably wished we could have removed in 34bf18b; the `SubsetProperties` of `Message` makes the meaning quite clear.

getHtmlPieceDescriptors tests: Start type-checking, use example data.

8f3fd72

getHtmlPieceDescriptors: Use Outbox's sender_id, now that we can.

34b6b31

From a search of `sender_email` in all JS files, I didn't see any other obvious places we could take advantage of `sender_id`. Part of zulip#3998.

types: Express Outbox as PmOutbox | StreamOutbox.

d346483

Like we did with `PmMessage` and `StreamMessage` in zulip#4506. We don't actually make `PmOutbox` any different from `StreamOutbox` in this commit; that'll come later.

chrisbobbe force-pushed the pr-outbox-sender-stream-ids branch from 9aeef9a to fce3e8b Compare May 10, 2021 18:33

chrisbobbe merged commit fce3e8b into zulip:master May 10, 2021

gnprice reviewed May 24, 2021

View reviewed changes

gnprice mentioned this pull request Sep 11, 2021

Implement stream action sheets #4899

Merged

chrisbobbe mentioned this pull request Sep 13, 2021

Add stream_id to Outbox values #5000

Merged

chrisbobbe deleted the pr-outbox-sender-stream-ids branch November 4, 2021 21:58

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Outbox type: Make `sender_id` required; add optional `stream_id`. #4667

Outbox type: Make `sender_id` required; add optional `stream_id`. #4667

Uh oh!

chrisbobbe commented Apr 16, 2021 •

edited

Loading

Uh oh!

WesleyAC left a comment

Uh oh!

WesleyAC Apr 20, 2021

Uh oh!

chrisbobbe commented Apr 20, 2021

Uh oh!

WesleyAC commented Apr 29, 2021

Uh oh!

chrisbobbe commented May 10, 2021

Uh oh!

gnprice left a comment

Uh oh!

gnprice May 24, 2021

Uh oh!

gnprice May 24, 2021

Uh oh!

chrisbobbe commented May 24, 2021

Uh oh!

Uh oh!

Uh oh!

Outbox type: Make sender_id required; add optional stream_id. #4667

Outbox type: Make sender_id required; add optional stream_id. #4667

Uh oh!

Conversation

chrisbobbe commented Apr 16, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

WesleyAC left a comment

Choose a reason for hiding this comment

Uh oh!

WesleyAC Apr 20, 2021

Choose a reason for hiding this comment

Uh oh!

chrisbobbe commented Apr 20, 2021

Uh oh!

WesleyAC commented Apr 29, 2021

Uh oh!

chrisbobbe commented May 10, 2021

Uh oh!

gnprice left a comment

Choose a reason for hiding this comment

Uh oh!

gnprice May 24, 2021

Choose a reason for hiding this comment

Uh oh!

gnprice May 24, 2021

Choose a reason for hiding this comment

Uh oh!

chrisbobbe commented May 24, 2021

Uh oh!

Uh oh!

Outbox type: Make `sender_id` required; add optional `stream_id`. #4667

Outbox type: Make `sender_id` required; add optional `stream_id`. #4667

chrisbobbe commented Apr 16, 2021 •

edited

Loading