[Custom UI] global:fullPage app fails to load

Forge Forge UI Kit and Custom UI
1

[Custom UI] global:fullPage app fails to load with generic “An error has occurred in loading this app.” — resolver never invoked, reproducible via both deployed dev environment and forge tunnel

Summary

A Forge Custom UI app using a global:fullPage module has stopped loading entirely. Jira/Confluence shows only the platform’s generic fallback:

An error has occurred in loading this app. Please try again later, or contact Atlassian support for assistance.

This happens consistently, in both Chrome and Firefox, whether the app is accessed via the deployed development environment or via forge tunnel. forge logs shows zero invocations when reloading the page — the app’s resolver function is never called, so the failure is happening before the platform even attempts to reach the app’s backend or serve its Custom UI bundle.

Environment

  • App ID: 43702860-9189-4fc9-829e-9c5e5f2d6b68
  • Environment: development
  • Site: chriphil70.atlassian.net
  • Module: global:fullPage (route prefix hello-world)
  • App version at time of issue: 5 (per forge install list)

What changed before this started

The app worked correctly (sprint picker, audience picker, report generation, rendered Markdown) up until we added a Confluence-publishing feature. That change added:

  • read:space:confluence and write:page:confluence to permissions.scopes
  • Two new resolver functions (listConfluenceSpaces, publishReportToConfluence) that call api.asApp().requestConfluence(...)
  • Initially, confluence: { required: false } under app.compatibility (later removed — see below)

After deploying that change and running forge install -p Confluence -s ``chriphil70.atlassian.net`` -e development, the Jira-side app stopped loading with the error above, and has not recovered since.

Steps already tried (all unsuccessful)

  1. Reinstalled the app for Confluence specifically once Confluence was provisioned on the site (was initially missing, causing an unrelated 404; that part is resolved).
  2. Removed app.compatibility.confluence entirely from the manifest (keeping only the two Confluence scopes) and redeployed with forge deploy --approve MAJOR_VERSION_RULE — no change.
  3. Ran forge install --upgrade for Jira to re-sync the install record after the manifest change — no change.
  4. Full forge uninstall (both Jira and Confluence) followed by fresh forge install (Jira) and forge install -p Confluence -s chriphil70.atlassian.net -e development — no change.
  5. Verified via forge install list that the installation is current (Status: Up-to-date) and used the exact current Installation ID in the app URL rather than a possibly-stale bookmarked one — no change.
  6. Tested via forge tunnel (bypassing the deployed CDN bundle entirely) using the correct, current installation URL — same generic error, and no activity in either forge logs or the tunnel terminal.
  7. Tested in both Chrome and Firefox — ruled out a browser-specific issue (e.g. third-party cookie/storage-access blocking).
  8. Checked https://status.atlassian.com — Jira and Confluence both show Operational.
  9. Confirmed via the browser’s network tab that the platform’s own loader (forge-apps.prod-east.frontend.public.atl-paas.net/assets/index.*.js) loads successfully (HTTP 200), makes a few gateway/api/graphql calls (also HTTP 200), and then itself fetches its own built-in error.svg — i.e. the platform’s own bootstrap script is the one deciding to render the error state, before ever requesting the app’s Custom UI bundle.

Question

Is this a known issue with global:fullPage apps that add/remove multi-product app.compatibility declarations and/or install against a second product after initial install? We found a related (but not identical) community thread about jira:fullPage apps throwing FCT_VALIDATION_CLAIM_MISMATCH in a similar multi-product scenario, reportedly fixed on Atlassian’s side in July 2026 — wondering if this is a recurrence or a different variant of the same underlying validation path.

Given forge logs shows no invocation at all (in both deployed and tunnel modes), this looks like an app/environment registration issue on the platform side rather than anything fixable from the manifest or resolver code. Any guidance on how to get this specific app/environment/site registration inspected or reset would be appreciated.

Happy to provide the app ID, additional request traces, or a screen recording on request.

2

Hi @ChrisPhillips, I’d say step 9 is where to dig again. Those gateway/api/graphql calls answer 200 and carry the real status down inside errors[].extensions, so the status column can’t see any of this. Open the Response pane rather than Preview, which truncates the nesting.

globalApp_extensionsByInstallationId is the query that bootstraps the full page, so look for whichever response carries it at the head of errors[].path. Per ECO-1706 the shell treats an error there as fatal, so nothing ever reaches your resolver. The FCT error you’re asking about lands in the same spot as statusCode: 400, and ECO-1319’s lands there as a 404 with classification: ProductMissingException. The body tells you which one you’ve got.

What’s in that errors array?

3

Thanks again for the pointer to globalApp_extensionsByInstallationId/extensionContexts and the errors[].extensions detail — I finally have something concrete from it, though it’s not quite the pattern you described.
New test: completely fresh site, fresh account permissions, checked minutes ago
To rule out anything left over from earlier testing, I set up one more completely independent combination:

  • New app registration (SprintExecReport, app ID 7b1c6ef2-fdae-4c78-80fc-9b2dea156b51), owned by a third, previously-untested Atlassian account.
  • Brand-new site (clipperitservices2.atlassian.net) that this account had never touched before.
  • Freshly granted Jira site-admin permissions (jira-administrators group) for that account on that site, granted only minutes before this test — so this isn’t stale/cached permission state from before.
  • forge install -s clipperitservices2.atlassian.net -e development completed successfully, confirmed three independent ways:
    • forge install list shows Up-to-date
    • The site’s own admin console (Manage apps) shows the app connected, “1 connection”
    • The site’s audit log has the install event logged with a timestamp
      Opening the app produces the same generic error as always:

An error has occurred in loading this app. Please try again later, or contact Atlassian support for assistance.

What the Network tab actually shows
Per your suggestion, I went through DevTools → Network → filtered on graphql, and inspected the Response body (not Preview) for all three gateway/api/graphql calls the page bootstrap makes on load:

  1. tenantContexts — succeeds normally, no errors, unrelated to the app.
  2. extensionContexts for the Confluence site ARI — succeeds, "extensions": [] (expected — this app isn’t Confluence-compatible).
  3. extensionContexts for the Jira site ARI (ari:cloud:jira::site/1e5122ad-06e3-421b-9da1-02000feea67c) — succeeds, **"extensions": []**.
    Importantly: there’s no errors key in any of these responses at all — "data" is the first and only top-level key in each. So this isn’t the FCT/ECO-1706 (400) or ProductMissingException/ECO-1319 (404) pattern — the GraphQL call itself is completely healthy and returns normally. It just reports that this Jira site has zero extensions, despite the install being confirmed through three separate channels (CLI, admin console, audit log) on that same site.
    That strongly suggests the actual bug isn’t in the app-loading GraphQL call itself, but in a propagation/sync gap between whatever backend records “this app is installed on this site” (which every management surface reads from correctly) and whatever backend the extensionContexts query reads from when the platform decides what to render. Those two appear to be out of sync for every installation I’ve tested — 5 apps, 5 sites, 3 separate Atlassian accounts at this point — despite the “installed” side being consistently correct.
    Happy to pull the same trace on any of the other reproductions, or share full request/response pairs (headers included) if that would help track down which service owns the extension registry that’s coming back empty.
4

No errors key at all is a different failure from the one I pointed you at, and it is the more useful finding. I sent you looking for a populated errors[] carrying a 400 or a 404. A healthy extensionContexts returning "extensions": [], for a site whose install is confirmed by the CLI, the admin console and the audit log, is neither ECO-1706 nor ECO-1319. I got the shape wrong, and your propagation-gap reading fits the evidence better than mine did.

Nothing is tracking it either. Searching ECO for extensionContexts returns no issues at all, and your thread is the only one in this forum carrying that exact error string. There is no ticket to add yourself to.

I would file it rather than wait. Five apps, five sites, three accounts, and an install confirmed three separate ways is a stronger report than most arrive as, and the empty array against a confirmed install is the single line that makes it reproducible for whoever picks it up.