Domains dashboard renders a failed fetch as "no custom domains"

[oguzkocer]

What happens

DomainsDashboardViewModel.refresh() fires three requests and treats a failure of any of them as an absence rather than an error:

• a failed site-domains fetch becomes an empty domain list
• a failed plans fetch becomes no domain credit
• a failed all-domains fetch becomes an empty list, which drops the status label and the tap target on any custom domain row

The screen has no error affordance at all — no message, no retry. So a site whose domains could not be loaded is drawn exactly like a site that has none: the free WordPress.com address, built from site.unmappedUrl when the response is missing, followed by a call to action inviting the user to buy a domain.

The same applies to the credit. If the plans request fails, "Claim your free domain" silently becomes "Add your domain", and a user with an unclaimed credit is shown a purchase flow instead.

Why it is worth fixing

This is not hypothetical. While testing #23305, two WordPress.com responses failed to deserialize, and the dashboard showed the free address and Add your domain for a site that has had a custom domain attached for years. Nothing on screen suggested a request had failed.

The screenshots in that PR make the point: the affected build online and a healthy build in airplane mode produced the same screen for the same site, pixel for pixel apart from the status-bar icon. Diagnosing it needed the in-app log viewer, because the UI carried no signal at all.

The user-facing consequences are the part that matters:

• someone can be invited to buy a domain they already own
• someone holding a domain credit can be shown the paid path instead, with no way to notice
• a transient network failure is indistinguishable from an account state, so retrying is not an obvious thing to do

Where

WordPress/src/main/java/org/wordpress/android/ui/domains/DomainsDashboardViewModel.kt — refresh() and buildDashboardItems().

Not a regression

Both trunk and the migrated version behave this way; #23286 preserved it deliberately, since changing it means designing an error state the screen has never had. This issue is that design work.

Possible directions

Not prescriptive — the shape is a product and design question, not just an implementation one.

• Distinguish "we could not load your domains" from "you have no custom domains", and offer a retry.
• At a minimum, suppress the purchase call to action when the fetch failed, so the app does not advertise something it cannot see the current state of.
• Consider whether a failed plans fetch should suppress the credit-dependent call to action rather than silently downgrading it.

The three requests fail independently, so partial success is the common case and the treatment probably differs per request rather than being one blanket error state.