Include permalink in error message when replied to message fails to load

[MadLittleMods]

Your use case

What would you like to do?

When a reply fails to load whether it be network or code related, include a permalink or at least event_id for the message it's trying to load so it's possible to reference and find the event in question.

Currently, the error message just says the following which has no details.

Unable to load event that was replied to, it either does not exist or you do not have permission to view it.

Why would you like to do it?

It's not easy to find the message it's trying to reference yourself or debug the situation. Just have to View source and dive into the gritty details.

How would you like to achieve it?

Add a permalink to the event in question. The event probably exists if someone is trying to reference it.

These kind of code or network fail cases are unlimited and cannot made to be impossible to encounter. We should strive to improve the fail scenario which could be a variety of solutions:

1. Just the event_id to reference. The bare minimum that should be available. "What failed to load?"
2. Permalink so you can try seeing the message for yourself in whatever manner. This solves the problem in code and network fail scenarios and makes it convenient to see the content you were missing.
3. A retry button to try reloading the message when conditions are better. But this one is susceptible to code bugs like the one explained at the top of this comment so I'm not in favor of it.
4. Other ideas

Have you considered any alternatives?

No response

Additional context

Related to:

• Forwarding a message which was a reply to another room has poor UX #19769

[t3chguy]

Given that its failed loading under the /event/ API then it realistically won't load as a permalink either (/context/ API) so a permalink doesn't do anyone much good, surely?

[MadLittleMods]

@t3chguy I think it would work. The message was visible elsewhere (related to #10856). And all of my /event and /context requests succeeded with 200. Plus a permalink will kick the timeline again to possibly make it load.

[t3chguy]

I think solving that issue by the suggestion in that issue would be far better then...

Looks like this is caused by the server being unhappy. We could probably intercept the calls that the replies make to pull from local cache first.

Giving a user a link which we know has a significant chance of just erroring is a smell.

[MadLittleMods]

Giving a user a link which we know has a significant chance of just erroring

I think this assumption is wrong. The link won't error in all cases. The reply could fail to load in many different ways, not just homeserver network issues.

Giving a user no detail on what went wrong or nudge on how to fix things on their own is a smell. Plus the current reason it gives is wrong for why it failed for me: "it either does not exist or you do not have permission to view it."

[t3chguy]

When would /event/ fail when a permalink (/context/) function fine, especially once fixing the local cache suggested in the other issue?

[MadLittleMods]

@t3chguy It could fail in the JavaScript code too. As an example in my case, /event/ didn't fail in my case yet the reply couldn't load.

If we're arguing that we should fix the JavaScript instead as well, yes! But any new regression can come in the future to cause replies to not load again (code can fail in many many unexpected ways). So there should be a escape hatch for users to workaround any problem in the mean time. The goal is to make error/fail scenarios better.

[t3chguy]

It could fail in the JavaScript code too. As an example in my case, /event/ didn't fail in my case yet the reply couldn't load.

Do you have logs to back that up? I haven't seen any JS failures in this area and don't see any open bugs with logs about them, all current known issues are server/network issue related.

[MadLittleMods]

Do you have logs to back that up? I haven't seen any JS failures in this area and don't see any open bugs with logs about them

@t3chguy Yes, No error was thrown as far as I can tell though, https://github.com/matrix-org/element-web-rageshakes/issues/11637#issuecomment-1076509447

I can even still reproduce so here is rageshake logs while staring at it, https://github.com/matrix-org/element-web-rageshakes/issues/11639

[t3chguy]

Turns out for reply fetching we still use the /context/ API rather than the /event/ one (/context/ is also used for fetching permalinks)

If no error was thrown then likely it wasn't a JS error, we rarely swallow errors.
Here we do swallow errors, but only if the /context/ fetch fails, would be good to log here regardless https://github.com/matrix-org/matrix-react-sdk/blob/3f67a389c148d661d024d0a0cfd8a9bc5f34e1f8/src/components/views/elements/ReplyChain.tsx#L169

Can you repro with your devtools open and observe the /context/ request?

[MadLittleMods]

Can you repro with your devtools open and observe the /context/ request?

@t3chguy Yes, 200 OK for /context/.

The place I can still reproduce is within a thread and replies and what not (around this sort of stuff #21533) but the point still stands. Things go wrong in unexpected ways and this same sort of thing could happen in the main timeline for a message that should be there.

[MadLittleMods]

Even after #21533 is now merged and deployed, I'm still seeing the problem around the same reply. It's a reply in the main timeline to a message that is in a thread. And since it's a reply, I am more confident, that it should be in the main timeline but just doesn't have access to the messages within a thread even though it was returned in the 200 OK /context/ response.

https://matrix.to/#/!fLeHeojWgBGJlLNdLC:matrix.org/$O8TE4QvivFsz_kstdni7L9yvn6O0scRV4iRbTOumUFQ?via=matrix.org&via=element.io&via=vector.modular.im

The case above is not a network problem but to add onto my point of a permalink still being useful in any case, we were just in a hotel with extremely spotty wifi. It's not out of the question for the first /context/ request to fail but then clicking the permalink will work in the wifi is flowing again to show the message you want to see. Going through a tunnel in a train with mobile data, a homeserver can go down for a second, then recover, etc. It's temporary.

These kind of code or network fail cases are unlimited and cannot made to be impossible to encounter. We should strive to improve the fail scenario which could be a variety of solutions:

1. Just the event_id to reference. The bare minimum that should be available. "What failed to load?"
2. Permalink so you can try seeing the message for yourself in whatever manner. This solves the problem in code and network fail scenarios and makes it convenient to see the content you were missing.
3. A retry button to try reloading the message when conditions are better. But this one is susceptible to code bugs like the one explained at the top of this comment so I'm not in favor of it.
4. Other ideas