# Race/sync issues with summary **URL:** \ **Category:** Mini Apps\ **Tags:** webxdc-api-future\ **Created:** [April 24, 2023, 3:49pm UTC](https://support.delta.chat/t/race-sync-issues-with-summary/2544 "2023-04-24T15:49:51Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![singpolyma](https://support.delta.chat/user_avatar/support.delta.chat/singpolyma/32/1795_2.png) [@singpolyma](https://support.delta.chat/u/singpolyma)\ **Post date:** [April 24, 2023, 3:49pm UTC](https://support.delta.chat/t/race-sync-issues-with-summary/2544/1 "2023-04-24T15:49:51Z")
Right now summary displayed on the WebXDC app message card is last-write-wins. Already I have seen this result in misleading results if eg two people vote in the poll app at once then they both send a summary of “1 vote” and so the summary says that even though there are 2 votes. Of course we can’t make a whole system for this that lives outside the app because most of the data is custom to the app and not specified at all (the whole point). So, my first thought I’ve had is, what if when a new WebXDC state update message comes in the client runs the WebXDC in a hidden webview (if it’s not open) and sends the state update there. Then instead of using this `summary` field to update the summary add a `webxdc.setSummary()` javascript API so the app can, based on its full knowledge of the current state, set a summary string. What do you think? ---
**Author:** ![WofWca](https://support.delta.chat/user_avatar/support.delta.chat/wofwca/32/1702_2.png) [@WofWca](https://support.delta.chat/u/WofWca)\ **Post date:** [April 24, 2023, 5:17pm UTC](https://support.delta.chat/t/race-sync-issues-with-summary/2544/2 "2023-04-24T17:17:57Z")
> [@singpolyma](#): > > when a new WebXDC state update message comes in the client runs the WebXDC in a hidden webview (if it’s not open) and sends the state update there Could you clarify your proposal? I don’t quite understand what’s the point of running a hidden instance. Either way, I don’t think running hidden app instances is the way to solve this, this sounds like a problem that the app itself must solve. I.e. if two apps send an update at the same time, they still are going to receive each other’s updates relatively quickly (as much as it takes to deliver a Delta Chat message), so each app instance still has the full state at the end of the day. In this case each instance, upon receiving the other app’s message, should sum up the actual number of votes and send another message with the updated `summary` (and perhaps an empty payload). ---
**Author:** ![singpolyma](https://support.delta.chat/user_avatar/support.delta.chat/singpolyma/32/1795_2.png) [@singpolyma](https://support.delta.chat/u/singpolyma)\ **Post date:** [April 24, 2023, 6:04pm UTC](https://support.delta.chat/t/race-sync-issues-with-summary/2544/3 "2023-04-24T18:04:25Z")
That is basically my proposal, to make the summary the WebXDC app’s problem. Having it just issue another summary message (rather than providing a new JavaScript API) is a way to acheive this, but I guess it relies on the app determining that the current summary was not correct, otherwise the instances will send summary messages back and forth forever. So yeah, my proposal was basically to remove the summary from the message entirely and make it up to the WebXDC app to update the local summary, since as you say it is the WebXDC app which has the full state at the end of the day. ---
**Author:** ![Simon](https://support.delta.chat/user_avatar/support.delta.chat/simon/32/287_2.png) [@Simon](https://support.delta.chat/u/Simon)\ **Post date:** [April 24, 2023, 8:47pm UTC](https://support.delta.chat/t/race-sync-issues-with-summary/2544/4 "2023-04-24T20:47:47Z")
I’m not sure we should do background worker stuff for webxdcs in the near future. Like we need to track the script so it won’t keep running in the background for longer than it needs to and stuff like that, maybe not even have something like full javascript but rather a small wasm function or rhai.rs script that gets run directly by deltachat core. The rhai.rs runtime has the option to set maximum operation count, that could be a way to limit it, so there can not be any loops. Maybe there are some wasm runtimes that have the possibility to track and limit operation count. But apple could be against running user generated code, so we need to be kinda careful what we do here, also security wise only have a very limited api, so security would be another reason against javascript. So I agree in principle, but nothing for the immediate near future IMO. ---
**Author:** ![hpk](https://support.delta.chat/user_avatar/support.delta.chat/hpk/32/9_2.png) [@hpk](https://support.delta.chat/u/hpk)\ **Post date:** [April 24, 2023, 8:50pm UTC](https://support.delta.chat/t/race-sync-issues-with-summary/2544/5 "2023-04-24T20:50:17Z")
> [@singpolyma](#): > > So, my first thought I’ve had is, what if when a new WebXDC state update message comes in the client runs the WebXDC in a hidden webview (if it’s not open) and sends the state update there. Then instead of using this `summary` field to update the summary add a `webxdc.setSummary()` javascript API so the app can, based on its full knowledge of the current state, set a summary string. i like the general idea and thought about it myself sometimes – but It’s unclear how easy/possible this “running in a hidden web view” is in practise – and it can also be quite problematic resource-wise and probably also security/privacy wise to instantiate web views and let 3rd party code run there on incoming app-update messages. If i disable “read receipts” i don’t want anything to respond when i am just looking at the message list of a chat. ---
**Author:** ![WofWca](https://support.delta.chat/user_avatar/support.delta.chat/wofwca/32/1702_2.png) [@WofWca](https://support.delta.chat/u/WofWca)\ **Post date:** [April 25, 2023, 3:44pm UTC](https://support.delta.chat/t/race-sync-issues-with-summary/2544/6 "2023-04-25T15:44:22Z")
> [@singpolyma](#): > > it relies on the app determining that the current summary was not correct The app could just set the summary regardless of what the current `summary` is. > [@singpolyma](#): > > otherwise the instances will send summary messages back and forth forever In this case the app could only update the `summary` only when it receives a new vote, and not when just `summary` is updated. But I’m still not sure if I get the proposal correctly. > [@singpolyma](#): > > to update the local summary Is this the point? To make `summary` separate for each user and not global (per-app), and keep it up-to-date with the help of a background process that listens to new messages? ---
**Author:** ![Simon](https://support.delta.chat/user_avatar/support.delta.chat/simon/32/287_2.png) [@Simon](https://support.delta.chat/u/Simon)\ **Post date:** [April 26, 2023, 7:15am UTC](https://support.delta.chat/t/race-sync-issues-with-summary/2544/7 "2023-04-26T07:15:44Z")
having some kind of processing background function for summary would also help us with localised summary, without having to duplicate the data on the wire (like translate on device instead of transferring summaries in all supported languages.) ---
**Author:** ![singpolyma](https://support.delta.chat/user_avatar/support.delta.chat/singpolyma/32/1795_2.png) [@singpolyma](https://support.delta.chat/u/singpolyma)\ **Post date:** [April 26, 2023, 2:37pm UTC](https://support.delta.chat/t/race-sync-issues-with-summary/2544/8 "2023-04-26T14:37:08Z")
> Is this the point? To make `summary` separate for each user and not global (per-app), and keep it up-to-date with the help of a background process that listens to new messages? Yes, that was my proposal. One thing that would be a step between here and there but not require a background process would be to just add the JavaScript API to allow updating a local-only summary. Then use summary messages to update the summary as we do now while the app is closed, but when you open the app it can set it to something fully correct when it runs. So it means you always get a correct summary at least right after you open it. ---
**Author:** ![WofWca](https://support.delta.chat/user_avatar/support.delta.chat/wofwca/32/1702_2.png) [@WofWca](https://support.delta.chat/u/WofWca)\ **Post date:** [April 27, 2023, 7:22am UTC](https://support.delta.chat/t/race-sync-issues-with-summary/2544/9 "2023-04-27T07:22:30Z")
Web extensions have a similar concept, it’s [“background scripts”](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Background_scripts). They can also be non-persistent, i.e. they only activate on certain events and get unloaded on idle. ---
**Author:** ![WofWca](https://support.delta.chat/user_avatar/support.delta.chat/wofwca/32/1702_2.png) [@WofWca](https://support.delta.chat/u/WofWca)\ **Post date:** [August 31, 2023, 2:17pm UTC](https://support.delta.chat/t/race-sync-issues-with-summary/2544/10 "2023-08-31T14:17:33Z")
> [@WofWca](#): > > this sounds like a problem that the app itself must solve. I.e. if two apps send an update at the same time, they still are going to receive each other’s updates relatively quickly My proposal of “it’s good enough the way it is” has a problem: it still is impossible to keep the `summary` (and `document`) updated in the case when two peers `webxdc.sendUpdate` and _immediately_ close the app, before they could receive each other’s updates (or just make sure that they both don’t have internet access when they send the messages). The `summary` could get updated when at least one app instance goes online, but it would remain incorrect before that. Though I think it’s a very rare case, with very minute consequences, and I right now it doesn’t seem to be worth writing an entire module just to solve it. ---
**Author:** ![r10s](https://support.delta.chat/user_avatar/support.delta.chat/r10s/32/1513_2.png) [@r10s](https://support.delta.chat/u/r10s)\ **Post date:** [October 6, 2026, 3:11pm UTC](https://support.delta.chat/t/race-sync-issues-with-summary/2544/11 "2026-10-06T15:11:17Z")