fix: Improve messaging & logging when adding Library Content (Beta) fails #35707
Conversation
…ails We have user-oriented messaging stuffed into the BadUpstream exception. We may as well use it rather than just giving an opaque error about xblock references. We also want to log this situation, since we'd expect that the library block usage key that Studio provides will generally be valid.
| f"Could not sync to new block at '{created_block.usage_key}' " | ||
| f"using provided library_content_key='{upstream_ref}'" |
There was a problem hiding this comment.
Sorry, belatedly occurred to me, but don't we need to translate this string if we're presenting it to end users?
There was a problem hiding this comment.
We're not-- that one just is going out to the logs.
The users see str(exc), i.e. the BadUpstream exception message, which we've already taken care to localize.
|
2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production. |
|
2U Release Notice: This PR has been deployed to the edX production environment. |
1 similar comment
|
2U Release Notice: This PR has been deployed to the edX production environment. |
|
2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production. |
|
2U Release Notice: This PR has been deployed to the edX production environment. |
1 similar comment
|
2U Release Notice: This PR has been deployed to the edX production environment. |
|
2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production. |
We have user-oriented messaging stuffed into the BadUpstream exception. We may as well use it rather than just giving an opaque error about xblock references.
We also want to log this situation, since we'd expect that the library block usage key that Studio provides should generally be valid. If it consistently isn't, that's an issue that operators are going to want to look into.
Before:
After: