Can you update/expand the guidance on maintaining cross-product Forge Marketplace apps?

Hi Team,

The current FAQ on What if my app supports multiple products? states that the Forge platform “supports and encourages developers to build apps that are compatible with multiple products”, though not yet for distribution via the Marketplace:

[…] If your app is compatible with multiple apps, you’ll need to create two Forge apps using the same code base, and publish two separate listings on the Marketplace.

We have followed resp. EAP advice to use the identical code base for Jira and Confluence and generate two manifests from a template, with the only differences between them being app name and ID, because the Forge runtime supposedly removes inapplicable scopes automatically.

This worked fine for a while, but yesterday we had our first (likely multi-dimensional) incident that effectively caused an app outage.

While not yet fully understood, the incident seems correlated to the (highly welcome) egress permissions rollout on Monday, which triggered a new ‘Allow access’ request for users. This grant flow worked in Jira, but always resulted in an error in Confluence (other users also encountered this).

We managed to work around the problem by explicitly removing the Jira scopes from the Confluence manifest, and instructing the linter to ignore the Jira specifics in the code based via --no-verify during deployment.

Both of these kludges would require a refactoring towards a likely more complex CI/CD pipeline, and might even require splitting inapplicable code paths from a product’s code base one way or another.

So before we go down this route, we would highly appreciate updated guidance on how to organize a code base for cross-product Forge apps distributed via the Marketplace - specific questions/asks seem to be:

  1. Is the Forge runtime still supposed to transparently handle cross-product deployments (i.e. removing/ignoring inapplicable scopes/code), which would suggest that we might have simply hit a regression or edge case?
  2. If that is not the case anymore, can you suggest alternative approaches, both short- and mid-term?
  3. Can you maybe provide a cross-product Marketplace sample app with CI/CD to make this easier for others developers down the road?

Many thanks,
Steffen

7 Likes

Hey @sopel,

I appreciate you taking the time to discuss the details of this with me offline. This is a rather complex problem.

The core of the problem here, to the best of my understanding, is the following:

  • The egress controls rollout required all apps to be consented to. In the past, your app had not required consent.
  • Because scopes are defined the same across asUser and asApp calls, your asApp scopes were showing up in the consent flow (even though you weren’t doing asUser calls).
  • This lead to cross-product scopes appearing in both apps consent flows (which is what would have happened regardless of the egress rollout if you were using asUser.

Forge on Marketplace does not support cross-product deployments natively, the EAP advice you mention is a workaround.

For short and long-term solutions, I may have to defer to @rfernandes.

2 Likes

Thanks @danielwinterw,

This helped us to get a better understanding of some aspects of this indeed multi-faceted and thus rather complex issue.

We have just filed a separate issue for one aspect that now turned out to be unrelated and only amplifying the impact during the incident:

We are unable to reproduce the main issue (consent grant flow does not finish in Confluence) with a privately distributed app, so it might indeed be related to the specifics of a cross-product Marketplace app, and we obviously don’t want to mess with our production deployment to debug this.

As a result, we are kinda blocked on reinstating your team’s cross-product app deployment advice as a workaround, so getting more insights and guidance by @rfernandes would be very much appreciated :slight_smile:

2 Likes