Certificate Wizard: show the real signing error instead of a blanket HTTP 502

[shai-almog]

A customer reported that for 24 hours, clicking Sync with Apple returned:

Codename One cloud signing service failed (HTTP 502). Try again later.

Their App Store Connect key was fine. So was the sync — it had already succeeded.

What was happening

Production logs show Apple answering one call with a 404:

GET /v1/appGroups?limit=200 status=404 code=NOT_FOUND
detail=The path provided does not match a defined resource type.

That is Apple saying the path is not a resource type it knows — App Store Connect does not offer App Groups to that account. (A collection that exists but is empty answers 200 with an empty data array.)

CloudSigningService.refresh() chains seven calls and loads App Groups last, and any failure there discarded the six that had already succeeded. afterMutation calls reload() on success, so the reconcile completed, the follow-up refresh died on call seven, and the developer was told to wait out something that had worked.

Two things then made it unreadable: the cloud service reported every Apple failure as 502, and CloudSigningService.message() short-circuited on code >= 500 and threw the response body away.

Changes

8635e0f09a — surface what the service actually said. The generated REST client already hands the callback the raw body on an error status (via the onErrorCodeString handler it emits), so the explanation was there all along. SigningError now reads it for every status and classifies the failure; the banner renders it with a next step attached — "Open ASC API Key" for a credential problem, "Try again" for something genuinely transient.

Bodies are not trusted blindly: a proxy or CDN in front of the service answers 5xx with its own HTML page or a stub like error code: 522, so a 5xx body has to read like prose before it reaches the UI. The banner became a SpanLabel because a Label clipped these messages to one line, and it stays selectable so the text can be pasted into a support thread.

7e432be24d — stop one optional call from discarding the account. By the time App Groups load, the six calls before them have proved both the Codename One login and the Apple key are good, so a failure there is treated as "no App Groups". The developer keeps their certificates, bundle IDs, devices, profiles and APNs keys on screen.

Specs track the server contract: NotConfigured becomes AscKeyProblem, and the Apple-calling paths document 422/429/404 alongside 502. openapi.json is regenerated from the yaml it is derived from.

Tests

38/38 green (mvn -B test), including:

• SigningErrorTest — the status→message mapping, including the CDN-stub and HTML-error-page cases that must never reach the UI.
• CertificateWizardErrorBannerTest — drives the real Sync with Apple button and asserts what lands on screen, that the old catch-all string is gone, and that the credential action navigates to the ASC API Key page.

Related

Server side is BuildCloud #130, which fixes the root cause (listAppGroups reads the 404 as "no App Groups") and stops flattening every Apple failure into a 502. Either side alone clears the customer's symptom: the server fix reaches everyone on a released wizard without a client update, and this one fixes a rebuilt wizard without waiting for a deploy.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.