-
-
Notifications
You must be signed in to change notification settings - Fork 315
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
Added fallback server option #1572
base: master
Are you sure you want to change the base?
Conversation
There are some caveats with using mirrors that need to be kept in mind and accounted for.
From what I can see in the diff, your changes probably sometimes forward more than just GET /api/skipSegments (most notably the POST /api/skipSegments endpoint, which is the submission endpoint mirrors currently will not accept) Also a question to think about: Should the fact that a fallback server is being used be indicated somewhere? |
I personally think it should be skip segments only |
I definitely agree, the fallback should only be used as a mirror to pull from, other requests should still use the main server. Let me make some changes to only have it on GET /api/skipSegments. @mini-bomba - any ideas on what would work best for this? I wouldn't want something as intrusive as a browser alert every time it fetches from the fb. Potentially an alert when choosing to upload segments if we previously used the fallback server, or some static text in the dialog aside the video player? (I'm not sure what you'd call it). |
Well that broke my commit :/ Set fallbackServer to false on the POST /api/skipSegments endpoint |
Probably makes most sense to have that in the popup. Instead of "Segments found on this video" say "Segments found on this video from the backup server" |
9a6f6f8
to
b407497
Compare
As the main server seems to be having some issues, I've added an option to use a fallback server when the main one fails. This defaults to "" (undefined) in the config, with users being able to set the URL below the standard URL option in options. If you've got testingServer set, this is overridden, and the form is removed from the options. How it works: Upon requesting sponsors, if the main server fails, we call retryFetch to try again. As we keep note of how many times we retry, we use the fallback server on every even retry, so it flips back and forth. The delay between retries has also been adjusted. 404 is the same, but if we've failed 2 or less times, we retry instantly, before going back to the previous delay setting. As most users are only concerned about fetching sponsors, we don't use the fallback server for requests regarding submitting data. We also only use the fallback server on asyncRequestToServer() calls, as nothing using the synchronous method would benefit.
May have accidentally reverted to the commit before and force pushed :/ Readded these, squashed commits.
This makes the most sense to me - Need some sleep but I'll get that done tomorrow hopefully. |
Maybe set some default fallback server? I don't think that average SponsorBlock user would search for fallback server by himself. |
Could perhaps have a list of mirrors sent by the server, have the extension remember it for a few days and pick a random server from the list every time it updates the list, as long as the user didn't modify it. But anyways, we probably should first implement the basic feature, then add further enhancements. |
No default fallback server for now |
Just finishing up implementing this, but noticed some strange behaviour - not sure if anyone more familiar may be able to shed some insight? The fallback switch works fine when loading a video without the main server reachable, but after switching videos a few times (in the recommended pane), it seems to stop working. It looks like it'll occasionally throw Unchecked runtime.lastError: A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received at some point, but this happens on a successful retry request as well. |
As the main server seems to be having some issues, I've added an option to use a fallback server when the main one fails.
This defaults to "" (
undefined
) in the config, with users being able to set the URL below the standard URL option in options.If you've got
testingServer
set, this is overridden, and the form is removed from the options.How it works:
Upon requesting sponsors, if the main server fails, we call
retryFetch
to try again. As we keep note of how many times we retry, we use the fallback server on every even retry, so it flips back and forth.The delay between retries has also been adjusted. 404 is the same, but if we've failed 2 or less times, we retry instantly, before going back to the previous delay setting.
As most users are only concerned about fetching sponsors, we don't use the fallback server for requests regarding submitting data.
We also only use the fallback server on
asyncRequestToServer()
calls, as nothing using the synchronous method would benefit.As mentioned in issues #1570 and #1562