Can't send messages to mobile-created streams

[gnprice]

A user reports:

If a stream was created from an Android phone, then Mobile devices (iOS and Android can't post into the Stream, they have the spinning wheel.
Desktop apps can post into the stream normal.

If a stream was created by iOS app or Desktop app, then posting from Mobile and Desktop all works fine.

Here's a screenshot of that spinning wheel:

The earlier message with no spinner was sent from desktop.

If the app is restarted, the messages with spinners disappear:

Note the matrix here: the issue apparently arises only if

• the stream was created on Android (iOS and desktop are fine)
• the attempted send is from Android or iOS (desktop is fine).

[timabbott]

I bet the issue has to do with how we're handling the stream and subscription event types.

When a new public stream is created, we would send a stream event type when a stream is created (letting the app know that a new stream exists, relevant for the "subscribe" UI) and a "subscrption" event if a user is added to a stream that already existed.

A common bug we used to have for this sort of thing in the webapp is having success handlers for HTTP requests that do things like update the local data structures to record the stream existing (or whatever). Instead, one should always do those inside the server_events_dispatch type handlers, and success handlers for HTTP requests should ~always just update progress indicators (etc.). The general consequence of that sort of bug is that the action (e.g. creating a stream) works properly only in the device/tab/etc. that does it, but not for any other devices. So we might want to audit the app for that category of issue as part of addressing this specific bug.

[borisyankov]

Thanks for the context @timabbott

I will examine two issues here:

• why are the messages not sent
• why after refresh they are gone, we should be caching them and resending them on restart

[borisyankov]

I tried creating from an Android, creating from iOS, then sending from Android or iOS and can not reproduce.

[gnprice]

I don't think we've heard reports of this bug in several years, and it seems like a class of bug that we've since fixed several of. So I'm closing it as presumed fixed -- especially since back when it was originally reported, we attempted to reproduce and already couldn't then.

A common bug we used to have for this sort of thing in the webapp is having success handlers for HTTP requests that do things like update the local data structures to record the stream existing (or whatever). Instead, one should always do those inside the server_events_dispatch type handlers, and success handlers for HTTP requests should ~always just update progress indicators (etc.). The general consequence of that sort of bug is that the action (e.g. creating a stream) works properly only in the device/tab/etc. that does it, but not for any other devices. So we might want to audit the app for that category of issue as part of addressing this specific bug.

This category of issue is basically covered by #3408. More specifically: I don't think we've tended to have bugs where we updated the local data structures too soon, on a successful request, but we have had bugs where we didn't properly handle the event, and #3408 is the umbrella issue for those.