RFC-137-B: Forge App Suspension Behaviour

General Request for Comments (RFC)
41

@JuliaDaehne, a bit late, and offtopic: “RFC-137” is already taken by RFC-137: Forge Module for AI Skills. You wanna re-number this one here to “RFC-138”?

42

Be good too if the search box worked for RFCs.

eg try search “RFC-137” and you’ll get zero results. Whole category isn’t indexed.

43

Thanks a lot @scott.dudley for taking the time to explain the challenges you are facing with the grace period condition. Your feedback allows us to better follow up with the relevant team supporting us with the implementation of an appropriate solution.
What you are describing in your suggestion 1 resonates with me and is one of the options we are considering - we will look into the maintenance end date coupling as well

44

@JulianMehnle do you know if the app is installed on a free Jira instance? It seems that there is a process for free Atlassian apps which suspends and eventually deletes the Atlassian app if inactive for a period of time. Is your Marketplace app is suspended as well? If no then this would be handled by this RFC’s solution

45

@scott.dudley when you are saying “When a paid subscription enters a grace period, the “inGracePeriod” flag is set to Yes, but the maintenance end date is also extended by 90 days” - are you using this API https://developer.atlassian.com/platform/marketplace/rest/v2/api-group-reporting/#api-vendors-vendorid-reporting-licenses-get?

This seems to be a reporting API rather than information you should obtain through invocation.

46

Hi @JuliaDaehne

Yes, my comment was referring to the MPAC reporting APIs. I cannot comment on anything other than the specification of the new Forge License API because I have not used it yet.

My point was mainly to express a hope that the Forge License API was not getting its data from the same source used by the MPAC APIs, because the timeliness and information fidelity of the latter is lacking what would be needed for the proposed uses in this thread.

47

Thanks everyone for the detailed feedback on this RFC. Here’s what we heard and where we’re heading:

  • Don’t hide app UI - show a suspension message. You’re broadly fine with stopping execution, but strongly opposed to apps silently disappearing. We’ll evaluate a platform-rendered notice as well as support a vendor-defined messaging during the app’s grace period.

  • Lifecycle events are essential. You need explicit suspend/unsuspend events - applicable to Forge remote as well.

  • Clarify product-specific behaviour. Jira workflow hooks, Confluence macros, and buffered event replay all need predictable, documented outcomes during suspension. We’ll work through these.

  • Continue evaluating buffered event replay behaviour, especially for longer suspension windows, and document expectations.

Thanks again for engaging with us on this - your input is directly shaping how we build this.

Julia

48

Thanks @JuliaDaehne , it is very refreshing to see an RFC working as intended.

(Too often it feels like some RFCs are “an announcement dressed up as an RFC” to soften the blow, with seemingly little intention of adapting based on feedback).

This RFC was not one of those, and it seems to have arrived at a great outcome for all.

49

It seems like this and the other RFC-137 were created in a human “race condition”. I’m going to rename them A & B to avoid rippling changes to RFC-138 (or any others that might be in draft). The naming does not indicate any intentional relationship between the 2. Sorry for the human error.