Skip to content

feat: Improve upload error message to show cause#2765

Merged
runningcode merged 4 commits intomasterfrom
no/eme-301-client-side-validation-of-vcs-provider-property-in-sentry
Sep 19, 2025
Merged

feat: Improve upload error message to show cause#2765
runningcode merged 4 commits intomasterfrom
no/eme-301-client-side-validation-of-vcs-provider-property-in-sentry

Conversation

@runningcode
Copy link
Copy Markdown
Contributor

@runningcode runningcode commented Sep 18, 2025

Summary

  • Improves error handling for invalid --vcs-provider parameter values
  • When backend returns “400 Unsupported provider" error, shows user-friendly message instead of generic API error

Before this PR:

WARN    2025-09-18 07:49:04.315821 +02:00 EXPERIMENTAL: The build subcommand is experimental. The command is subject to breaking changes and may be removed without notice in any release.
> Preparing for upload completed in 0.114s
  WARN    2025-09-18 07:49:05.135782 +02:00 Failed to upload 1 file:
  WARN    2025-09-18 07:49:05.135865 +02:00   - /Users/nelsonosacky/workspace/hackernews/android/app/build/outputs/apk/debug/app-debug.apk (API request failed)
error: Failed to upload any files

After this PR:

  WARN    2025-09-18 09:40:30.389061 +02:00 EXPERIMENTAL: The build subcommand is experimental. The command is subject to breaking changes and may be removed without notice in any release.
> Preparing for upload completed in 1.233s
  WARN    2025-09-18 09:40:32.341187 +02:00 Failed to upload 1 file:
  WARN    2025-09-18 09:40:32.342033 +02:00   - /Users/nelsonosacky/workspace/hackernews/android/app/build/outputs/apk/debug/app-debug.apk
  WARN    2025-09-18 09:40:32.342108 +02:00     Error: API request failed
  WARN    2025-09-18 09:40:32.342144 +02:00     Cause: sentry reported an error: Unsupported provider (http status: 400)
error: Failed to upload any files

Closes EME-301

🤖 Generated with Claude Code

When the backend returns "Unsupported provider" error for invalid
--vcs-provider parameter, show a user-friendly error message instead
of the generic API error.

Closes EME-301

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
@runningcode runningcode requested review from a team and szokeasaurusrex as code owners September 18, 2025 05:59
@linear
Copy link
Copy Markdown

linear bot commented Sep 18, 2025

Comment on lines +312 to +326
// Check if this is the "Unsupported provider" error and provide a better message
let error_message = if let Some(source) = e.source() {
let source_str = source.to_string();
if source_str.contains("Unsupported provider") {
if let Some(provider) = vcs_info.vcs_provider {
anyhow!("The VCS provider '{}' is not supported. Please check the --vcs-provider parameter.", provider)
} else {
anyhow!("The VCS provider is not supported. Please check the --vcs-provider parameter.")
}
} else {
e
}
} else {
e
};
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few thoughts:

  • This deep nesting makes it difficult to understand what the code is doing. It should be possible to rewrite as a single if/else or match statement by chaining methods (like map) onto the option (you may even be able to solve it only with method chaining, no if/else/match needed)
  • Rather than making a new error with anyhow, we should call .with_context on the original error, so the original error is preserved. The context should be the main error message
  • Also, where is the "Unsupported provider" message coming from? Is it getting returned by the server? The current implementation just checking that the error string contains this message seems a bit brittle to me, as it would break if the server changes the error message, or if another error includes this string. If the only indicator of this error is this message, however, I guess it is ok to check directly against it. Still, rather than just doing a simple string contains operation, we should downcast the error to the appropriate type and check the field where the message would be set.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good point. I’ve updated the PR to pass the message directly from the server to the client. That should address 1 and 2.

Regarding 3: the error message is coming from the server here. getsentry/sentry@8a21a5a

runningcode and others added 2 commits September 18, 2025 09:36
Remove complex string matching logic and display error source directly.
This shows the actual server error message (e.g., "Unsupported provider: xyz")
instead of generic wrapper messages like "API request failed".

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
Display file path on first line, then show Error and Cause on
indented lines for better readability and clearer error context.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
Thank you!

Co-authored-by: Daniel Szoke <7881302+szokeasaurusrex@users.noreply.github.com>
Copy link
Copy Markdown
Member

@szokeasaurusrex szokeasaurusrex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! But, before merging, please update the PR/squashed commit title, as this change is no longer specifically improving VCS provider error messages, but is more generally improving the error messages for all file processing errors.

@runningcode runningcode changed the title feat: Improve error message for unsupported VCS provider feat: Improve error message to show cause. Sep 19, 2025
@runningcode runningcode changed the title feat: Improve error message to show cause. feat: Improve upload error message to show cause Sep 19, 2025
@runningcode runningcode merged commit a81510b into master Sep 19, 2025
25 checks passed
@runningcode runningcode deleted the no/eme-301-client-side-validation-of-vcs-provider-property-in-sentry branch September 19, 2025 09:47
runningcode added a commit that referenced this pull request Sep 19, 2025
## Summary
- Improves error handling for invalid `--vcs-provider` parameter values
- When backend returns “400 Unsupported provider" error, shows
user-friendly message instead of generic API error

Before this PR:
```
WARN    2025-09-18 07:49:04.315821 +02:00 EXPERIMENTAL: The build subcommand is experimental. The command is subject to breaking changes and may be removed without notice in any release.
> Preparing for upload completed in 0.114s
  WARN    2025-09-18 07:49:05.135782 +02:00 Failed to upload 1 file:
  WARN    2025-09-18 07:49:05.135865 +02:00   - /Users/nelsonosacky/workspace/hackernews/android/app/build/outputs/apk/debug/app-debug.apk (API request failed)
error: Failed to upload any files
```

After this PR:
```
  WARN    2025-09-18 09:40:30.389061 +02:00 EXPERIMENTAL: The build subcommand is experimental. The command is subject to breaking changes and may be removed without notice in any release.
> Preparing for upload completed in 1.233s
  WARN    2025-09-18 09:40:32.341187 +02:00 Failed to upload 1 file:
  WARN    2025-09-18 09:40:32.342033 +02:00   - /Users/nelsonosacky/workspace/hackernews/android/app/build/outputs/apk/debug/app-debug.apk
  WARN    2025-09-18 09:40:32.342108 +02:00     Error: API request failed
  WARN    2025-09-18 09:40:32.342144 +02:00     Cause: sentry reported an error: Unsupported provider (http status: 400)
error: Failed to upload any files
```



Closes EME-301

🤖 Generated with [Claude Code](https://claude.ai/code)

---------

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Daniel Szoke <7881302+szokeasaurusrex@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants