we are experiencing a time lags where the client’s messages take 3mins to display in CHT .
Also the “pending” and “received” gateway messages that display for messages in CHT are inaccurate feedback for health worker. These messages display yet the client has already received the message. It appears as though it takes many minutes for this message to get sent ie
CHT:
sent message at exactly 2:30 pm (PCT)
message received by gateway at 2:30pm (PCT)
as of 2:35pm the message had not been forwarded by gateway
Joel received the message at 2:30 (PCT) // in other words the “pending” and “received” messages in CHT are incorrect as the message is already received by client but CHT displays “pending”
We want this to feel like instant messaging between busy healthcare workers and clients, so having a few minutes between messages disrupts the flow. Any thoughts on what could be brewing this ? @diana@jkuester@mrjones
Hey @cliff. Can you clarify - are you using TextIt (RapidPro) with RapidPro android gateway, or are you using CHT’s SMS functionality with CHT’s gateway?
When the client sends a message to your RapidPro system, it gets received quickly by the RapidPro Android Channel. I believe you’re experiencing a delay between the Android channel and the RapidPro server.
Outbound messages with RapidPro can feel instantaneous, but inbound messages are slower. This is a RapidPro limitation, not a limitation of the CHT.
I believe outbound messages move quickly because the system relies on FireBase to trigger the data synchronization on demand. Sadly, the inbound data isn’t guaranteed to move quickly and only happens after a 10 minute poll.
We’ve had the same challenges with our 2wt systems and so we have a custom fork of the rapidpro-andorid-channel which shortens the poll interval from 10 minutes to 3 minutes. That fork isn’t appropriate for your use, since it doesn’t work with TextIt - but you could theoretically prepare, sign, and maintain a similar fork which shortens that interval. It can tighten things up a bit, but it still won’t feel instantaneous. Alternatively, you could work with the RapidPro community for system improvements? https://groups.google.com/g/rapidpro
@kitsao@jonathan Can you please make any corrections if I’ve made mistakes here? Or if you have any ideas for cliff?
We’re working on real-time text messaging between clients and health workers, and we’re noticing that CHT displays a state of received that’s not documented in the SMS states.
In our experience, the time that “received” shows is the time the message was texted in by our test users, and not the time that this message actually apperas in the CHT (per what Kenn outlined above).
So for a healthworker engaging in real-time texting, the message actually appears in CHT several minutes after it was sent, but the time stamp as if it was received minutes earlier. This is confusing.
@kenn and team - would you all add a definition for received to the SMS message states section that clarifies what it’s measuring? And I wonder if there could be a better way to show the display time instead, though I defer to @cliff who is exploring this issue with our in-country Gateway provider too.
On the received state, can you please share where you are seeing this state?
Is it in the UI? When you are exporting messages? Do you only see this state for incoming messages?
My suspicion is that this status doesn’t actually get assigned to am outgoing message, and this is the reason it’s not documented.
Incoming messages (messages that are received by the CHT from incoming sources) don’t have actual states, because no action is associated to them. States are used for outgoing messages, that do have actions and tracking associated with them. An incoming message state is terminal.
I’m looking at webapp code and it seems that we “default” to received when the message doesn’t actually have a state. This is always true for incoming .
This state also seems to be pushed to the message state history when exporting incoming messages.
Ah, I see! You might be right! The timestamp of the status that is stored on the document is when API received the state-change from the text-it gateway that the message had been sent.
I wouldn’t think of it as a bug, because the recorded timestamp is correct (as the time when API has received the status notification), just not the information you are looking for. We’ve integrated text-it as a messaging gateway, so it’s possible that other messaging gateways (our cht-gateway for sure) do not send status updates that also have timestamps. For that matter, text-it doesn’t either, but the response includes a sent_timestamp.
We could create an issue to investigate and improve this in such a way that we could potentially benefit for other messaging gateways.
