Troubleshoot an SDK release
Open the affected target's release view. Keep the intended version, generation PR, release PR and linked workflow run together while investigating. Never paste tokens, private logs or unredacted provider responses into an issue.
| Symptom | Next step |
|---|---|
| Repository absent | Refresh authorization with I don't see my repo; check the installation's selected repositories. |
| Approval pending | Have an installation administrator review the App update on GitHub. |
| Secret missing or name collision | Inspect the named repository/environment secret. Preserve a credential used by another workflow; do not overwrite it blindly. |
| OIDC authentication failed | Compare exact owner, repository, workflow and environment with the provider's trusted publisher. |
| Workflow failed | Read the failing job. Fix the cause before using the release view's targeted retry. |
| Released, no receipt yet | Check the linked run and callback step. Let reconciliation inspect provider truth; do not fabricate or replay callback bodies. |
| Registry says published, Studio disagrees | Check the exact package/version and attribution. Existence alone does not prove it came from this release. |
| Repository-managed publishing detected | Compare workflows and publishing preference with your intended configuration. A repository administrator may have changed them. |
| Unlink cleanup incomplete | Follow the manual inventory, including provider credentials; losing App access is not proof of cleanup. |
One target succeeded and another failed
Section titled “One target succeeded and another failed”Do not rerun the whole release set or republish the successful child. Use the per-target state to identify the unfinished version, fix its failure, and retry only that child. Keep the intended version unchanged unless the registry already contains incompatible bytes under it. Ask support when the retry cannot be tied to an exact occurrence.
The wrong version or content was published
Section titled “The wrong version or content was published”Treat released versions as immutable. Preserve the incident evidence, stop further Doctorine automation if needed, and prepare a corrected version through a new reviewed release. Use the registry's supported deprecation or yank controls only after checking consumer impact. Do not delete and recreate a version or move a tag to make the history look successful.
Custom code conflicts
Section titled “Custom code conflicts”Resolve the change on the base branch, rebuild and review the resulting generation PR. See Custom code. A closed generation PR can be reopened on GitHub; creating unrelated release branches does not repair its lifecycle.
Ask for help
Section titled “Ask for help”Share the target, bounded error/status shown in Studio, intended version and links to the relevant private release/run with authorized support. Exclude credentials, customer payloads and raw request/response bodies. An estimated or unknown state must be reconciled, not relabeled as published.