List in pkg/registry/apps/application/rest.go builds its answer from the HelmReleases that carry the application kind and group labels. When ConvertHelmReleaseToApplication fails for one of them, the loop logs the error and goes on with continue (rest.go#L428-L429). The response has no error and nothing that marks the missing item. The watch path does the same (rest.go#L945-L946).
Get handles the same failure differently and returns conversion error: ... (rest.go#L301-L302). So kubectl get <kind> <name> fails with an error for an application that kubectl get <kind> does not show at all. Anything that counts instances through the API, like a script, the dashboard, or a runbook that compares counts, gets a number that is short and is not told so. The only trace is a line in the cozystack-api log.
This covers every application kind, since they all use the same REST storage. I have not seen a conversion fail on a real cluster. Today the error paths are in defaulting (applySpecDefaults), so this is about how a failure is reported, not how often it happens.
It is up to the maintainers whether the whole list should fail, or the item should come back with a condition that says it could not be read.
Listinpkg/registry/apps/application/rest.gobuilds its answer from the HelmReleases that carry the application kind and group labels. WhenConvertHelmReleaseToApplicationfails for one of them, the loop logs the error and goes on withcontinue(rest.go#L428-L429). The response has no error and nothing that marks the missing item. The watch path does the same (rest.go#L945-L946).Gethandles the same failure differently and returnsconversion error: ...(rest.go#L301-L302). Sokubectl get <kind> <name>fails with an error for an application thatkubectl get <kind>does not show at all. Anything that counts instances through the API, like a script, the dashboard, or a runbook that compares counts, gets a number that is short and is not told so. The only trace is a line in the cozystack-api log.This covers every application kind, since they all use the same REST storage. I have not seen a conversion fail on a real cluster. Today the error paths are in defaulting (
applySpecDefaults), so this is about how a failure is reported, not how often it happens.It is up to the maintainers whether the whole list should fail, or the item should come back with a condition that says it could not be read.