Hello @zulip/server-streams members, this issue was labeled with the area: stream settings label, so you may want to check it out!

What would happen when some other streams takes the old name of the other stream?

Wow, thanks for the quick feedback! I described this case in the issue:

If someone then re-created a new A, the redirect would no longer apply.

Does this make sense?

Ah, missed that part. Makes sense 👍

The default strategy I'd probably take with this is the same that we currently use for PM threads, basically putting the ID of the object into the URL:

https://chat.zulip.org/#narrow/pm-with/857-joshuapan8

So we'd be doing here e.g.

https://chat.zulip.org/#narrow/stream/123125-A

I don't think that change would be super difficult to implement. Downsides include:
(1) If you're writing documentation or something, you can't just enter a permanent link by typing the URl structure from memory, you need to actually go grab it from the Zulip UI so you get the stream ID.
(2) the change would probably break all existing links, unless we're going to ban names starting with "[0-9]+-" from the space of valid stream names, so that one can parse both formats. In which case, I suppose we could support the sloppy form of links as well; they just wouldn't have the benefits of surviving a stream rename.

Thoughts? I think that this model is probably simpler than making a StreamAlias table that contains redirects from old stream names to new ones, at the cost of making the URLs somewhat less attractive.

Thanks @timabbott ! I should have read this earlier :-)

the change would probably break all existing links

Yeah, that's the part that breaks my use case (preserving historical links from the FHIR issue tracker, mailing list, etc). I wound up taking a naive stab at something more like the StreamAlias, mostly as an exercise in (re)familiarizing myself with the codebase.

There are challenging bits that I haven't tried, like updating the client-side rename list when stream names change while the client is running (thought it's vaguely possible this works correctly, given that the server-side tests pass). My sense is it's probably less work to throw this out and start something new (since 95% of my effort was understanding the codebase), but not sure whether I'll have the time for it.

I'll send along a PR for what's there.

OK, now that I have some tests in place and have figured out where to hook the logic into the frontend, I'm much happier with this. If it's getting close enough to be at all plausible for inclusion in 1.6 @timabbott that'd be awesome (but otherwise we can always deploy in FHIR's fork).

I think this is a bit ambitious to get into 1.6, which we're hoping to release pretty soon.

I definitely like some of the ideas here:

• We should persist old names with something like StreamAlias, as shown in your PR. We'll want to make absolutely sure there's a DB index on the name field.
• On the client side we can have a simple mapping of old_stream_name -> stream_id, and we can try to find the most surgical places to swap in the "current" name for things like filtering.
• We can fix the hashes to include stream id like we did with PMs--I think this will largely solve the problem of somebody posting a link on a blog or similar that gets out of date due to a rename.

We should probably discuss this on chat.

I like the last solution.

@jmandel well, this took longer than might have been ideal to happen, but I'm pretty happy with the solution in #8400. Thanks again for bringing this issue to our attention! :)