deltachat
allow resending/forwarding other's messages/webxdc?
I filed this bug under the DC android client but it seems like it's actually in the chatmail core, as re-sending the app to chat doesn't refresh it for this particular client like it's been marked deleted and cannot recover.
-
Android version: Android 13
-
Device: OnePlus Nord2 5G
-
Delta Chat version: 2.10.0 (happened with 2.9 as well)
-
Expected behavior: apps available in chat
-
Actual behavior: On my android client the app does not show up in the Apps view in the chat, On my windows desktop client (updated to 2.10.0) i see the app fine and can interact with it regularly. My chat partner in this chat also on android DC 2.9.0 can also work with the app normally. Attempting to resend the app to chat from the working desktop client doesn't result in any visible change. Replying to the original app 'message' from the desktop client shows up as a reply on the bugged android client, but tapping on the contents of the original message produces an error. Changing the state of the app (adding a new expense in the case of the splitbill app) doesn't result in any visible change for the bugged client, but works fine on desktop for me and my chat partner's android client. The only fix seems to be removing the profile on the device and re-adding it as a second device, copying the whole state from my desktop where the app still shows up.
-
Steps to reproduce the problem: Unclear, i am in several other groups with many webxdc apps there and they all seem to work fine. Only this app has disappeared.
-
Screenshots: View from bugged android client after desktop replies to original app posting:
-
Logs: I can post the log if necessary but it's unclear to me what information there is too identifying or could possibly compromise my app's security.
If a message (incl. webxdc apps) was removed locally (for any reason), we keep its tombstone for 48 hours to prevent re-downloading it. After that it should be possible to resend the message from your other device and it should visible again, in case of a webxdc message -- with all status updates, i.e. the actual app state is re-sent too. Have you already tried waiting for this period?
@iequidoo i can try! i think last time i did wait at least 24 hours with retrying before wiping and reimporting as a second device to fix it, maybe not a full 48s
the bigger question of course is why is this one webxdc getting deleted to begin wtih, especially as it's happened twice now
the bigger question of course is why is this one webxdc getting deleted to begin wtih, especially as it's happened twice now
For now i can't answer this. But at least here we see that this 48-hour period added in 72bfae9448b27d76a74f7213f59f49965ac74ba8 complicates using webxdcs. Other types of messages the user can just forward, but a webxdc needs to be re-sent so that all status updates are re-sent too.
In #7121 i want to trigger housekeeping() right after the program start, maybe in this case it should prune all message tombstones w/o checking if that period has passed. At least for webxdcs. CC @link2xt
...
An alternative is to reduce that period for webxdcs, maybe to several minutes so that they are really usable in such a scenario.
Ok update on my particular test case: sadly unlike the first time this happened where my phone 'lost' the app but my second device (PC) still had it and i was able to restore my state by re-adding phone as second device, this time both the phone and the PC don't have the app.
There's no UI option for the other person in the chat to re-send the app because they aren't the one that sends it. I dont understand exactly why that is the case but i'll leave that up to someone who understands more 😁 I think in this case we've truly 'lost' the app, luckily it was a split-the-bill so we can delete it fully and recreate the state by hand.
There's no UI option for the other person in the chat to re-send the app because they aren't the one that sends it.
So we have a missing functionality here. Webxdc status updates are created by all app participants, but only one who originally sent the app can resend them. The others can only forward the instance itself. It makes sense to allow resending incoming webxdc messages, in this case no new webxdc message should be added to the chat, not sure if it's possible to display a "sending spinner" for incoming messages, maybe we should add a system message like "You re-sent the app ..." clicking on which should bring the user to the original message. Currently, if the original sender lost the message or left the group, new members can't use the app. Would be good to solve this with minimal UI changes for now, i.e. only display "Resend" for incoming webxdcs. CC @link2xt @Hocuri @r10s @hpk42
There's no UI option for the other person in the chat to re-send the app because they aren't the one that sends it.
Yes. this on purpose.
I dont understand exactly why that is the case but i'll leave that up to someone who understands more
This is because we do not have the functionality to send a message on behalf of others at all.
it is doable, but requires careful considerations, and it is unclear if we want to have it at all in general or only for selected things as webxdc.
resend webxdc was added as a total side project to somehow allow members later coming to get the app.
if the original sender is no longer available, one still needs to send it again (at best with export and import)
Would be good to solve this with minimal UI changes for now, i.e. only display "Resend" for incoming webxdcs.
not sure what you mean here, maybe a typo :) however, "Resend" is displayed only for outgoing webxdc.
closing this issue as there is no actionable item. it is unfortunately that the webxdc is lost, but the migration thing happens only one time (and we won't adapt migration code to not introduce new states and bugs based on different migrations)
not sure what you mean here, maybe a typo :) however, "Resend" is displayed only for outgoing webxdc.
Yes. Actually i wanted to ask how easy it is to show "Resend" for all webxdc messages. In Core resending of any webxdc is doable.
This is because we do not have the functionality to send a message on behalf of others at all.
We don't need "send on behalf of..." here, we need just resending, for new members the message should be displayed as one sent by the new sender. In other words, it should act like forwarding with all status updates.
This issue isn't about resending webxdcs though, that was just my side question, and it's not about the migration to 2.x (@jackaperkins, please correct me if i'm wrong), so it should be reopened because it's still under investigation what happened exactly and how we can help the user.
This isn't about the 2.x migration
Correct, I do think it's a separate issue. I should be clear this has happened now twice with the same app in the same chat. Both times happened after the 2.x migration, but not simultaneous with it, so I don't believe it's related directly in the sense of a bad DB migration incorrectly updating state between v1 and v2.
The first time i was able to get the state back by removing my phone's account and re-adding it as a second device, so the app state was cloned from my PC. the second time the app was removed on both phone and PC. For my own use i'll recreate the state manually by adding a new copy of the app, and i'll keep a close eye on it. Other apps in other chats seem to behave fine, not sure why this one has been singled out.
We don't need "send on behalf of..." here, we need just resending, for new members the message should be displayed as one sent by the new sender. In other words, it should act like forwarding with all status updates.
not sure if that is a good idea, that might be confusing when suddenly a message is sent with a different name. maybe okay if it is flagged as being "Forwarded", but that would make the option less universal for resending non-webxdc, much context is lost.
maybe it is better and good enough to add a tide (~Bjoern), as we do for bots that impersonate a lot eg. for bridges. that way it is clear, it may not be the original.
still, if this is what we're talking about, this is not a bug, but a feature proposal where we should agree on a way first
not sure if that is a good idea, that might be confusing when suddenly a message is sent with a different name. maybe okay if it is flagged as being "Forwarded", but that would make the option less universal for resending non-webxdc, much context is lost.
I think technically it should be forwarding and displayed so, but with two changes: it must preserve Message-ID and attach status updates. But from the UI perspective "Forward" already does what it does, so it's better to add "Resend" for incoming webxdcs (and that's closer to what "Resend" does for outgoing ones). It shouldn't affect the existing "Resend" functionality.
And yes, this is a feature proposal, but the current situation when you should wait for the original sender to come back and resend the app isn't good.
As for the reported bug when even a re-sent webxdc isn't received because of the existing message tombstone, i suggest:
- Reduce the tombstone TTL to one day as it was suggested in https://github.com/chatmail/core/issues/3685#issuecomment-1649848646 (?)
- Prune all tombstones after the program start (restarting is a natural way to solve problems). Maybe tombstones don't need to be stored in the db at all, but let's not change a lot for now. Alternatively, we can only store a tombstone if a message isn't on IMAP yet, but not sure it'll work well for e.g. Gmail who duplicates sent messages in "Sent".
Introducing a smaller TTL for webxdc tombstones is possible, but currently we don't store the tombstone type and the TTL should be really small which breaks https://github.com/chatmail/core/commit/72bfae9448b27d76a74f7213f59f49965ac74ba8 for webxdcs.