fix(artifacts): Report error for unknown artifact types in distribution#567
fix(artifacts): Report error for unknown artifact types in distribution#567runningcode wants to merge 2 commits intomainfrom
Conversation
…on (EME-422) Replace the TODO in _do_distribution() with a call to _update_artifact_error() so that unsupported artifact types are properly reported back to Sentry instead of silently failing.
When a ZippedXCArchive has an invalid code signature or is a simulator build, _do_distribution now reports the specific error via _update_artifact_error instead of silently doing nothing. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| artifact_id, | ||
| ProcessingErrorCode.ARTIFACT_PROCESSING_ERROR, | ||
| ProcessingErrorMessage.UNSUPPORTED_ARTIFACT_TYPE, | ||
| ) |
There was a problem hiding this comment.
Distribution sets global artifact error state
Medium Severity
_do_distribution() now calls _update_artifact_error() for simulator builds, invalid signatures, and unknown types, which updates the artifact’s global error_code/error_message. If other requested features (e.g. size analysis) succeeded, this can overwrite a successful artifact state with a distribution-only failure, potentially misreporting overall processing status.
| logger.info(f"BUILD_DISTRIBUTION for {artifact_id} (project: {project_id}, org: {organization_id})") | ||
| if isinstance(artifact, ZippedXCArchive): | ||
| apple_info = cast(AppleAppInfo, info) | ||
| if apple_info.is_code_signature_valid and not apple_info.is_simulator: |
There was a problem hiding this comment.
cursorbot said that if a ZippedXCArchive has an invalid code signature or simulator build, it silently does nothing so this addresses that.


When
_do_distribution()encounters an unknown artifact type, it only loggedan error but never reported the failure back to Sentry via
_update_artifact_error(). This left the artifact in an inconsistent statewhere distribution was requested but silently failed.
Now calls
_update_artifact_error()withARTIFACT_PROCESSING_ERROR/UNSUPPORTED_ARTIFACT_TYPEso the failure is surfaced to users.Fixes EME-422