Notify server that update has failed

[co-dax]

[riderx]

Thanks for the report @co-dax Event update_fail has been add to v4 if you wanna try it it's in beta

[co-dax]

Not working in v 4.3.7 manual mode android. I didn't check iOS yet. The event "updateFailed" is not being fired when we omit calling "CapacitorUpdater.notifyAppReady()" in the newly set version.

[riderx]

Thanks for the report, i have to check deeper, in the code i can see this should happen

[brianzamorano]

Confirmed that this isn't working in 4.4.2 as well for iOS.

[riderx]

Sorry for the mistake guys, updateFailed is sent to the JS as event and update_fail is sent to the stats URL. I will try to investigate more

[riderx]

@brianzamorano you use this ?

  CapacitorUpdater.addListener('updateFailed', (res) => {
    console.log('updateFailed', res)
  })

Because i see the event happening with that one. I also receive well the event in my Capgo test:

If you need to configure custom stats endpoint https://docs.capgo.app/self-hosted/auto-update#statistics

[co-dax]

@riderx I once again came upon this issue and found this thread that I created time ago but I forgot I about it.

I would say the issue here is that at the followig line of code it is reloading the webview immediately so most probably it the webview itself does not make it in time to get notified the the plugin (java code)

...I had such issues in the past when I was sending a request to the backend and almost immediately closing/reloading desktop browser web tab so the http request was not actually sent to the backend even though the line for executing the xhr request was executed just before the line for closing/reloading the web tab.

[riderx]

Thanks @co-dax forreporting again, I'm scared to put a delay on this since the reload has to be done asap in the user phone. Maybe i could do the reset first and then after a delay send the JS event ?

[riderx]

I think that better since the current version is supposed to be broken.

[co-dax]

@riderx I doubt any timeout would result in a deterministic result (unless we make it so long that we noticeably block the app) and it just does't "feel" semantically correct..It just seems a kind of a workaround but hey if there is no other solution then it is what it is.

One possible approach could be to save into CapacitorPreferences the fact that we have just reverted the version we just tried installing and then notify that the version has been reverted/cancelled via an event from CapacitorUpdater when the webview loads as a result of the version rollback itself. That way we could be prettry sure the request sent from that event handler to the backend server would make it through it terms of time.

There might another approach to take so that before reloading we raise an event to the webview informing the webiview that the update has failed and then wait for the webview to inform us (via a CapacitorUpdater plugin function) that we can proceed and thus reload the window. The webview would inform us (via a CapacitorUpdater method as menioned above) that is safe to reload the webivew through some custom logic that would make sure the logging request has been sent to the backend server. But I would say this would mae things more complicated both for you and for all developers using CapacitorUpdater so I would prefere the the first approach from above where the webview would be notified about the failed version update just after the webview is reloaded and the app started again within the webivew.

I hope I was clear.

[co-dax]

@riderx I just came upon this issue once again and forgot I had actually reported it.

The point is that "updateFailed" event is effectively not working since the webview is not being informed about the failed update due to the the reload being triggered immediately.

It might be the case for CapacitorUpdate to take not that the update has failed by written that value with Preferences plugin before resetting and reloading the webview then allow developers to either:

1. Allow developers to use some newly added CapacitorUpdater function to see if there has been a failed update (the function would return the version of the failed update) so this would be a way to allow developers to know there has been a failed update. This approach is does no require the entire native app to be restart so the information regarding the failed update would be provided almost in real time as the only delay would be due to the webview being reloaded. There should also be a CapaciotorUpdater function for developers to reset/remove failed update information from CapaciotrUpdate (which would then remove that information from Preferences plugin where it would actually keep that information internally)
2. ...or store information about failed update in Preferences plugin then check for that information (internally within CapacitorUpdater) on the next native app start, raise the "updateFailed" event appropriately and then remove related info from Preferences plugin (internally within CapacitorPlugin). Note that this approach would require native app cold restart for the updateFailed event to be fired so the firing of updateFailed event would be detailed until the next native app cold start.

I would say the first approach is less appealing with regards to developer experience but it would be more reliable as it would be almost in real time. ...now that I am writting about that an elegant fix just came into my mind to improve developer experience with the first approach...you could still keep the implementation from the first approach from above and still keep the same interface for "updateFailed" event but just re-implement the logic behind "updateFailed" event firing so that:

1. As soon as the developer subscribes to updateFailed you then query Preferences plugin to see if there is a failed update and then fire the event immediately so the developer would get the updateFailed event fired then you should remove related information regarding the failed update from Preferences plugin so that it does not fire again on the next app start or webview reload. The only problem that I can see with this approach is that only the first subscriber would get informed since you would remove related information about the failed update form Prefenreces plugin immediately (as mentioned above) which would prevent the next subscribers to get the event fired...but this seems to be a minor issue.

Please let me know if you plan on fixing updateFailed event as I otherwise I will implement the principle the first approach above in my front end code.

Let me know if I was not clear above.

[riderx]

@co-dax I think there is already a wait to partially achieve what you want with the list method. That gives you the list of bundle in the phone and the status. The only problem is: The error status is not explicit enough and does not give you the reason. Can be something to improve in the future

[co-dax]

Yeah, thanks @riderx