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

Show error summary from API when transcript fails to load #1030

Merged
merged 2 commits into from
Jul 5, 2023

Conversation

robertknight
Copy link
Member

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

Testing:

  1. Go to http://localhost:9083/https://www.youtube.com/watch?v=e-43x-H4CNY
  2. You should see the error message below:
Transcript error display

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.

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('')
Copy link
Member Author

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];
Copy link
Member Author

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>
Copy link
Member Author

@robertknight robertknight Jun 30, 2023

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.

Copy link
Contributor

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.

@lyzadanger
Copy link
Contributor

@robertknight Can you help me understand the goal of the "details" box once it's more functional?

@robertknight
Copy link
Member Author

@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.

@lyzadanger
Copy link
Contributor

lyzadanger commented Jul 5, 2023

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:

Could not retrieve a transcript for the video https://www.youtube.com/watch?v=e-43x-H4CNY! This is most likely caused by: Subtitles are disabled for this video If you are sure that the described cause is not responsible for this error and that a transcript should be retrievable, please create an issue at https://github.com/jdepoix/youtube-transcript-api/issues. Please add which version of youtube_transcript_api you are using and provide the information needed to replicate the error. Also make sure that there are no open issues which already describe your problem!

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 <details> element until it has something useful to say. Looks like it's easy to drop in?

@robertknight
Copy link
Member Author

robertknight commented Jul 5, 2023

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?

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 detail field for this particular error, and so the <details> field would not be shown.

We don't currently have a case where we have extra information to show. I would expect the backend to simply omit the detail field whenever it has nothing to add.

@lyzadanger
Copy link
Contributor

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 detail field for this particular error, and so the <details> field would not be shown.

So, maybe we could punt on the <details> element for now until we have a clear need for it?

@robertknight
Copy link
Member Author

So, maybe we could punt on the

element for now until we have a clear need for it?

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)
@robertknight
Copy link
Member Author

Done! - The <details> is now gone.

Copy link
Contributor

@lyzadanger lyzadanger left a 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>
Copy link
Contributor

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', () => {
Copy link
Contributor

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?

Copy link
Member Author

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} />
Copy link
Contributor

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.

Copy link
Member Author

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 }));
Copy link
Contributor

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.

Copy link
Member Author

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.

@robertknight robertknight merged commit 917e3a1 into main Jul 5, 2023
7 checks passed
@robertknight robertknight deleted the api-errors branch July 5, 2023 14:15
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