-
Notifications
You must be signed in to change notification settings - Fork 7
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
Show error summary from API when transcript fails to load #1030
Conversation
The API returns JSON:API error objects with `code`, `title` and `details` fields. Show the `title` to the user instead of a generic "API call failed" message. Part of #1028
); | ||
assert.equal( | ||
wrapper.text(), | ||
['Unable to load transcript', 'Something went wrong'].join('') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[...].join('')
is used here to separate out parts that are on different lines in the UI, but that don't have actual spaces between them.
Array.isArray(resultData.errors) && | ||
resultData.errors.length > 0 | ||
) { | ||
error = resultData.errors[0]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The JSON:API format allows for multiple errors, but we currently only report the first one on the frontend. I'm not aware of a scenario where we'd expect the backend to report multiple yet.
<p>{error.error.detail}</p> | ||
</details> | ||
)} | ||
</div> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Styling is obvious not final here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, don't worry about that for now. I've got it.
@robertknight Can you help me understand the goal of the "details" box once it's more functional? |
I was thinking it would work like the "Details" box in LMS error messages. It could include any technical information that we think might be useful for debugging or other purposes. In the LMS context, the support/success team for example will often open this if they are on a call with a user and inspect / make note of what is in there. |
Are you fairly convinced that it adds value? I know you want it to be tweaked, but right now it reads:
AFAICT that doesn't add any information or use beyond what the concise error message says. Can you give me an example of what it might say in future that would be useful? Edited: A plausible path forward could be to omit the |
There is an open issue at #1044. What I am expecting as a result of resolving that issue is that the backend would omit the We don't currently have a case where we have extra information to show. I would expect the backend to simply omit the |
So, maybe we could punt on the |
OK, I'll do that. |
We have decided to remove this for the moment as we don't have a good example where it provides value. We'll re-add it when we do. See #1030 (comment)
Done! - The |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your patience! I'm working on collating some error-styling needs into a single ticket to track, so, I got that part.
<p>{error.error.detail}</p> | ||
</details> | ||
)} | ||
</div> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, don't worry about that for now. I've got it.
import TranscriptError from '../TranscriptError'; | ||
|
||
describe('TranscriptError', () => { | ||
it('displays just `Error.message` if there are no error details', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this test description need adjustment in light of the details
removal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still valid as "error details" includes the title. This case is for when we don't have a server-generated error at all, or it doesn't include even a title.
<div data-testid="transcript-error"> | ||
Unable to load transcript: {transcript.message} | ||
</div> | ||
<TranscriptError error={transcript} /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's neat that the same reference can accommodate either an actual transcript or an error (and am of the opinion that typing makes this possible versus a bug waiting to happen). But I admit I did a double-take at error={transcript}
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I might rename this to transcriptOrError
in future.
it('throws exception if result is not JSON', async () => { | ||
fakeFetch | ||
.withArgs(videoPlayerConfig.api.transcript.url) | ||
.resolves(new Response('<b>Oh no</b>', { status: 500 })); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just confirming that we intend to invent a 500 here in these cases :). Granted this is not new behavior in these changes, so feel free to ignore me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is mean to simulate something like eg. a 5xx "Bad Gateway" error if the server failed to respond within the various timeouts that the proxies in front have.
The API returns JSON:API error objects with
code
,title
anddetails
fields. Show thetitle
to the user instead of a generic "API call failed" message.Part of #1028
Testing:
Note that the error title and contents of the "Error details" box need a bunch of work on the backend to refine. For example subtitles are not so much "disabled" for this video as "not available" because the video doesn't have spoken words. This morning I also encountered the same error message for a video where the transcript just hadn't been generated. In the frontend we are just displaying what the backend sends.