Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[content-service] show error if failed to download backup file #10491

Merged
merged 1 commit into from
Jun 8, 2022

Conversation

sagor999
Copy link
Contributor

@sagor999 sagor999 commented Jun 6, 2022

Description

Make sure to show if there was an error attempting to download backup, if any.

Related Issue(s)

Related #10315

How to test

Release Notes

[content-service] make sure to show error if there was one when attempting to download backup

Documentation

@sagor999 sagor999 marked this pull request as ready for review June 6, 2022 21:30
@sagor999 sagor999 requested a review from a team June 6, 2022 21:30
@github-actions github-actions bot added the team: workspace Issue belongs to the Workspace team label Jun 6, 2022
}
if err != nil {
return src, xerrors.Errorf("cannot restore backup: %w", err)
Copy link
Member

Choose a reason for hiding this comment

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

why the xerrors change?

Copy link
Contributor

Choose a reason for hiding this comment

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

If we use xerrors, we get a warning that we have to use fmt instead of it.

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

@aledbf Thanks for your information. I haven't seen it. You are right.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hm. I was under the impression that we will be slowly switching to fmt instead of xerrors.
@easyCZ I think it was in one of your PRs that this was discussed, unless I am mistaken.

Copy link
Member

Choose a reason for hiding this comment

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

Hm. I was under the impression that we will be slowly switching to fmt instead of errors.

Same here. Maybe the guide is not clear about that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Same here. Maybe the guide is not clear about that?

The guide is clear IMHO: it promotes xerrors (on purpose).

Thanks @kylos101 for linking the Slack thread. We didn't really land on a change, because

  • fmt.Errorf neither carries, nor perpetuates a stack trace
  • github.com/pkg/errors would produce a stack trace, but is deprecated and yet another third party library

xerrors is not ideal, but

  • it works
  • it is reasonably consistent throughout our codebase. Until we decide to do something else we should keep it this way to ease migration "search + replace" style.
  • it's not deprecated
  • it comes from the Go team themselves.

All that said, xerrors also isn't exactly future proof, and we could look for alternatives in an RFC.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated PR.

@roboquat roboquat merged commit bc74f87 into main Jun 8, 2022
@roboquat roboquat deleted the pavel/10315 branch June 8, 2022 21:18
@roboquat roboquat added deployed: workspace Workspace team change is running in production deployed Change is completely running in production labels Jun 21, 2022
@utam0k utam0k mentioned this pull request Dec 19, 2022
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: workspace Workspace team change is running in production deployed Change is completely running in production release-note size/XS team: workspace Issue belongs to the Workspace team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants