The Applications page reuses list-modules, the Software Center action that queries every enabled repository over HTTP(S). When a repository is unreachable or disabled, the page stalls in a loading state for ~20s (each repository call burns its own timeout, sequentially, uncached), and the same reuse causes #8139: an app's locally-shipped logo is discarded in favor of the generic placeholder whenever the repository is unreachable. Applications page only needs to know what is already installed in the cluster, a local concern, while Software Center's job is discovering what can be installed from remote repositories; reusing one action for both ties local-only UI to remote-repository latency and failure modes.
Proposed solution
Give the Applications page a way to get its data without ever contacting a repository: a new list-applications cluster action, local-only by design. It would never perform a repository HTTP request and would only return data derivable from the cluster itself (installed instances, locally-shipped app metadata and logo, cluster-wide update settings). Remote-only information (available updates, full version catalog, certification level) would be omitted; the UI would merge it in later with a separate list-modules call, ideally loaded progressively (show the local list first, then unfold "update available" once list-modules returns).
This would let the Applications page render instantly, regardless of repository reachability, and would fix the logo fallback in #8139 as a side effect, since the local logo would be part of the response instead of being discarded in the UI.
Alternative solutions
Add an offline input parameter to the existing list-modules action instead of a new action. When set, it would skip every repository request and return only locally-derivable data for installed instances, with no updates reported. This reuses the existing action and output shape, but keeps the local-only guarantee opt-in (easy to forget) and, since the response shape stays the same either way, would still expose remote-oriented fields (certification level, repository identity, screenshots) with placeholder values instead of omitting them.
Alternatively, keep a single list-modules action and no offline mode, instead trying to make the existing repository loop resilient (e.g. cache negative results, run repositories in parallel, shorten timeouts). This would reduce the wait (see also #8088) but would not remove the Applications page's dependency on remote repository availability, and would not by itself address the logo fallback disagreement in #8139.
Additional context
No approach has been chosen yet; this issue tracks the decision and the follow-up implementation, including the corresponding Applications page frontend changes (progressive loading, using the local-only source of truth for logos and installed-app data).
See also
The Applications page reuses
list-modules, the Software Center action that queries every enabled repository over HTTP(S). When a repository is unreachable or disabled, the page stalls in a loading state for ~20s (each repository call burns its own timeout, sequentially, uncached), and the same reuse causes #8139: an app's locally-shipped logo is discarded in favor of the generic placeholder whenever the repository is unreachable. Applications page only needs to know what is already installed in the cluster, a local concern, while Software Center's job is discovering what can be installed from remote repositories; reusing one action for both ties local-only UI to remote-repository latency and failure modes.Proposed solution
Give the Applications page a way to get its data without ever contacting a repository: a newlist-applicationscluster action, local-only by design. It would never perform a repository HTTP request and would only return data derivable from the cluster itself (installed instances, locally-shipped app metadata and logo, cluster-wide update settings). Remote-only information (available updates, full version catalog, certification level) would be omitted; the UI would merge it in later with a separatelist-modulescall, ideally loaded progressively (show the local list first, then unfold "update available" oncelist-modulesreturns).This would let the Applications page render instantly, regardless of repository reachability, and would fix the logo fallback in #8139 as a side effect, since the local logo would be part of the response instead of being discarded in the UI.Alternative solutions
Add anofflineinput parameter to the existinglist-modulesaction instead of a new action. When set, it would skip every repository request and return only locally-derivable data for installed instances, with no updates reported. This reuses the existing action and output shape, but keeps the local-only guarantee opt-in (easy to forget) and, since the response shape stays the same either way, would still expose remote-oriented fields (certification level, repository identity, screenshots) with placeholder values instead of omitting them.Alternatively, keep a single
list-modulesaction and no offline mode, instead trying to make the existing repository loop resilient (e.g. cache negative results, run repositories in parallel, shorten timeouts). This would reduce the wait (see also #8088) but would not remove the Applications page's dependency on remote repository availability, and would not by itself address the logo fallback disagreement in #8139.Additional context
No approach has been chosen yet; this issue tracks the decision and the follow-up implementation, including the corresponding Applications page frontend changes (progressive loading, using the local-only source of truth for logos and installed-app data).
See also