Hi @janette , when an admin uninstalls a Forge app it will enter a soft delete state for 30 days. During this time Atlassian can recover the app’s data if requested by the customer.
The 60 seconds between uninstall request and eventual uninstallation of the app happens before the soft delete state. Any developer cleaned up data such as for instance Jira entity properties will not be soft deleted and cannot be recovered.
Hi @jbevan for your storage clean up you should be able to do this after receiving the pre-uninstall trigger.
Forge hosted storage on the other hand wouldn’t need to be cleaned up as this is handled as part of our app lifecycle, ie post installation an app will be in a soft delete state for 30 days. During this time the data can still be recovered if the customers asks us to do so. After this time time the data will be deleted.
Hi,
Why is the event called preUninstall and not simply Uninstall?
What happens if the 60s timeout is breached or if the application fails to respond to the event? Will the uninstall continue anyway?
One problem with the Connect uninstall event is that if the customer’s license expiry and he doesn’t explicitely uninstall the application, we never receive an uninstall event. Additionally the License API for cloud apps doesn’t return an expiry date. So, we had to build all sorts of workaround by getting data from the Marketplace to decide if we can delete some customer’s data or not. This is very error prone and we end up keeping data for very long even if the customer doesn’t have a valid license.
As someone says in the thread, sometimes the whole Jira instance is gone and we never get any uninstalll event.
It would be nice if you could tackle this problem and either make the license expiry date available in the License API or uninstall automatically the app when the user doesn’t have any valid license (with some retention period).
Hi @osiebenmarck the console should show logs generated by the site that uninstalled the app. We save the logs for a period of 30 days.
Correcting: “the console should show logs generated by the site that uninstalled the app”. We do save the logs for 30 days but we don’t currently show them on uninstalled sites. We would need to look into this further. Thanks for bringing this up
2 Likes
Hi @BrunoMarotta an uninstall event would come too late. If we were to send an uninstall event the app would be undiscoverable and any compute cleanup that needs a link to the app to be executed would fail (also see @JoshVawdrey comment in the thread above).
For apps with expired license that are not uninstalled by customers we are introducing a new platform behaviour https://developer.atlassian.com/changelog/#CHANGE-2876.
1 Like
Hi @EdijsVilci here is a remote manifest example
# Forge Remote
# `preUninstall` example
modules:
preUninstall:
- key: remote-pre-uninstall
endpoint: remote-pre-uninstall
endpoint:
- key: remote-pre-uninstall
remote: remote-app-node
route:
path: /hooks/uninstall
auth:
appSystemToken:
enabled: true
permissions:
scopes:
read:app-system-token
remotes:
- key: remote-app-node
baseUrl: https://forge-remote-refapp-nodejs.services.atlassian.com
1 Like
Thanks all for your comments thus far. There appears to be a requirement to better understand what happens to different types of data after an uninstallation. The current state is:
- Some data (such as Forge Storage, KVS, SQL) will enter a ‘soft delete’ state after uninstallation. This data can be recovered by the customer within a 30 day period through an Atlassian customer service process. We are aiming to move this to a self service admin flow in Connected Apps in the future
- Other data (such as data from remotes or configuration) is not taken care of by the Forge platform. Such data can be deleted by partners following a preUninstall trigger.
We understand the limitations of a 60sec limit between an uninstall trigger and the actual uninstallation may not give you sufficient time to run your clean up operation, depending on the app. Unfortunately as mentioned in one of the threads above the uninstallation process is part of a more complex backend workflow that must succeed in a timely manner. The 60sec window is therefore a hard requirement.
Follow up items:
- persist app logs of uninstalled apps for a period of time after uninstallation process is concluded
- investigate how to run more platform driven post uninstallation clean up operations to reduce the burden on partners
1 Like
@JuliaDaehne, as noted by other partners as well, I expect that for many partners the data cleanup also consists of a ‘soft delete’ with a X day retention, and a hard delete afterwards.
This is a pattern that many partners already apply, and given the hard requirement of a 60s limit between the trigger and actual uninstallation, this is the only feasible pattern.
This does leave us with one more question which has not been directly addressed:
Customers can ask Atlassian to recover ‘soft’ deleted data within 30 days. If partners also implement the ‘soft’ delete approach, is there a way for Atlassian to notify partners that the app has been reinstated and data has been recovered?
It feels like there should be a ‘recovered’ event or state that is linked to the uninstall event, that will provide partners with old&new identifiers (if applicable) to allow us to also initiate the recovery process on our end. Otherwise customers will end up with a weird state in which data on the Atlassian side is recovered, but data on partner side is still in limbo.
4 Likes
How exactly does this look from the app’s perspective? Is the old data going to suddenly appear in the storage for the new installationId, or is the old installationId going to become active again? What happens if there is any new data added while the old data was soft deleted, and then the customer restores their old data?
1 Like
Hi @remie the proposed recovery and relinking of app data and app configuration is indeed something we have started to look into. It is a pretty complex exercise which is why we will likely focus on the ‘self serve’ data storage recovery first. If there is a requirement from partner side to recover and relink other app data we could address this through a future 'soft delete data recovery" RFC.
To your question about the current soft delete process: the old installationID will not become active again. Based on the history of the app we find the stored data of the old app and make it available to the new installationID. We don’t override on conflict - so if a different value for the same key is set in the new installation this would be retained
Ok, so any solution that would support data recovery on the partner side will need to somehow include providing both old & new installation ID
1 Like
For what it’s worth, we use cloudId+appId to do this, as this is stable.
2 Likes
Same approach used here to re-link remote stored data, but we also retain the previous installationId so that we have both current and historic installationId, allowing us to supply to the customer or through ECOHELP to allow re-linking of Forge KVS data.
1 Like
@JuliaDaehne on that note that the installation IDs will change, I’d want to raise the importance of guaranteeing and documenting other stable identifiers we can use as requested in Forge Site Id Documentation .
As a partner I’d prefer relying on a stable identifier that will also be the same after uninstallation/reinstallation as @tobias.viehweger pointed out as well.
1 Like
Noted @tobias.viehweger and @matthias . I left a comment
1 Like
Following final summary I will close this RFC.
The discussion touched on a lot of adjacent topics such as soft delete, data recovery and app/ cloud IDs. We will follow up on these outside the scope of this RFC and your feedback gave us a good starting point. As always: thanks for taking the time to take part in the discussion!
2 Likes