Markdown - Large code blocks are not displayed until user refreshes the page

[isagoico]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Log in to e.cash as account A
2. Navigate to a conversation with account B
3. Open a incognito tab and log in to account B
4. Send a large code block to account A
5. Navigate back to account A and check the conversation with account B

Expected Result:

Message with large code block is displayed

Actual Result:

Message is not displayed. User needs to reload the page sothe message is displayed.

Workaround:

User needs to refresh the page.

Platform:

Where is this issue occurring?

Web ✔️
iOS
Android
Desktop App
Mobile Web

Version Number: 1.0.74-0

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Grabando.193.mp4

Expensify/Expensify Issue URL:

View all open jobs on Upwork

---

From @MonilBhavsar https://expensify.slack.com/archives/C01GTK53T8Q/p1624957028202800

Large code blocks are not rendered until page is refreshed on web and app is restarted on desktop.

[MelvinBot]

Triggered auto assignment to @HorusGoul (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[HorusGoul]

Things that I've found:

• The issue can be reproduced locally.
• It affects all kinds of large messages, not only code blocks.
• It's related to the 10kB limit imposed by Pusher. More info on that: https://support.pusher.com/hc/en-us/articles/360019115473-What-is-the-message-size-limit-when-publishing-a-message-in-Channels-
• This code should prevent this, but it doesn't:
  https://github.com/Expensify/Web-Expensify/blob/ae58ce1f1e0f20eab21a72ff5e3669830a72e544/lib/Push/Service.php#L119-L129
• The problem I see with that code is that we're measuring the payload size and not taking into account the modifications that Pusher's library applies to it. Inside the pusher-php-server code, we can find lines that encode or encrypt the payload, and these operations definitely change the size of the message, and if it exceeds the 10kB limit, the push message won't be sent.
  https://github.com/pusher/pusher-http-php/blob/v4.1.4/src/Pusher.php#L526-L535

Solutions to solve this problem:

a. We could implement one of Pusher's suggestions.
b. Add client-side validation to avoid messages from exceeding X number of characters, so we can be sure that it will fit in a Pusher notification.
c. Split large messages into multiple messages like Telegram does it. We could implement this on the client.

I'd implement (b) or (c) as preventive measures to avoid messages from getting lost during a conversation and then work in (a) until we are sure it works with any size. Once (a) is ready, we could remove (b) or (c) as an improvement. I think N7 could be great because the improvement is aligned with the need to send "long important messages" related to the business.

Also, if you try to send a text with a size of 3.5kB, it won't be received in the other end because the payload size exceeds the 10kB limit. What do we include in it to make it almost 3 times bigger? Is all of that necessary?

Invoking the @Expensify/engineering team: What solution would you pick?

[tgolen]

I believe we have support already for (c). If you look here, all of that code should be able to handle multiple "chunks" of a single pusher message that is sent over multiple requests. I don't exactly remember how that code works, but I think @johnmlee101 was the one that wrote and implemented most of it, so he could hopefully provide some more context for us.

[HorusGoul]

Cool! If there's already support in the app for this, the only thing left would be sending the messages in chunks from the server to the Pusher API.

[johnmlee101]

Yeah! For new versions of the apps we should be able to handle pusher requests (at least the ones used for Inbox Calls). There might be some API changes required to make sure this flow works (as we don't want to disrupt the mobile app for older version support), but should be straightforward.

[HorusGoul]

Should we open a new issue related to the API changes? We could also close this one as we don't need to change anything on the client-side.

[marcaaron]

There might be some API changes required to make sure this flow works (as we don't want to disrupt the mobile app for older version support), but should be straightforward.

To clarify, we are currently not sending report comments in chunks and will start doing so? I'm curious how we can do this without breaking existing mobile clients (Expensify not Expensify.cash) who are not set up to process chunks (most important maybe being Concierge in the current app). Pusher implementation here is not set up for chunks (as the implementation predates the chunking change).

It's hard to tell which client you are sending a message to or whether they can support chunking so the clearest way to achieve this is to send the events to a channel that we know can support the chunking. Maybe there's a better way since that will result in a ton of potentially unnecessary events?

Maybe this is less of a concern as I'm not too sure what happens when a mobile client tries to handle a message that is chunked. Maybe we handle it gracefully and the message just doesn't appear? If so, then it's less of a concern.

[tgolen]

I don't think the old mobile app uses pusher at all, does it?

…

On Thu, Jul 1, 2021 at 12:33 PM Marc Glasser ***@***.***> wrote: There might be some API changes required to make sure this flow works (as we don't want to disrupt the mobile app for older version support), but should be straightforward. To clarify, we are currently not sending report comments in chunks and will start doing so? I'm curious how we can do this without breaking existing mobile clients (Expensify not Expensify.cash) who are not set up to process chunks (most important maybe being Concierge in the current app). Pusher implementation here is not set up for chunks <https://github.com/Expensify/Mobile-Expensify/blob/b733fc9fc66b69c9c558a821aa0eb9f4bc5c4d49/app/managers/PusherManager.js#L179-L184> (as the implementation predates the chunking change). It's hard to tell which client you are sending a message to or whether they can support chunking so the clearest way to achieve this is to send the events to a channel that we know can support the chunking. Maybe there's a better way since that will result in a ton of potentially unnecessary events? Maybe this is less of a concern as I'm not too sure what happens when a mobile client tries to handle a message that is chunked. Maybe we handle it gracefully and the message just doesn't appear? If so, then it's less of a concern. — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#3797 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJMAB3KJQMUQ2TCCY6KX4TTVSYJFANCNFSM47QYVOWQ> .

[marcaaron]

Linked the code where it is used above. But yes, realtime report comments, Concierge widget, etc