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.

Sign up for GitHub

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

Jump to bottom

Report bridge failure after multiple consecutive failures #994

Closed
logmanoriginal opened this issue Jan 5, 2019 · 3 comments
Closed

Report bridge failure after multiple consecutive failures #994

logmanoriginal opened this issue Jan 5, 2019 · 3 comments
Assignees
@logmanoriginal
Labels
Need-Info Additional information required New-Feature This is a new feature

Comments

@logmanoriginal
Copy link
Contributor

#841 changed error reporting to return feed items (every 24 hours) instead of setting the HTTP header. That way users get notified if a bridge is broken instead of it silently failing.

While this works well, some servers will report issues for non-broken bridges. This can be caused by slow connections from either the host or remote server.

Instead of reporting errors directly, I suggest adding a report queue where all bridge requests are buffered (the results of those). If a bridge fails for the same reason multiple times, the user gets notified. Otherwise the bridge silently fails and returns the cached data.

The report queue should handle any number of bridges with the last n failed requests. When a bridge request succeeds, the queue for that bridge is cleared. Otherwise the failure is added to the queue and after n failed requests, an error is reported to the user.

The limit n for the number of failed requests should be adjustable in the configuration.

Let me know what you think is a good solution for that.
This issue will also serve as primary case for all reported issues (reference to this issue if possible).
@logmanoriginal logmanoriginal added New-Feature This is a new feature Need-Info Additional information required labels Jan 5, 2019
@logmanoriginal logmanoriginal self-assigned this Jan 5, 2019
This was referenced Jan 5, 2019
Closed
Closed
@rEnr3n rEnr3n mentioned this issue Jan 6, 2019
Closed
@em92
Copy link
Contributor

em92 commented Jan 6, 2019

The report queue should handle any number of bridges with the last n failed requests

n is 0 on:

  • debug mode
  • when If-Modified-Since header is NOT set (example, on first request on bridge instance)

Otherwise the bridge silently fails and returns the cached data

I would suggest just to return 304 Not modified without adding any cached data, which may not exist. Sure, it must be returned if If-Modied-Since is set.

@logmanoriginal
Copy link
Contributor Author

Thanks for the feedback!

n is 0 on:

* debug mode

* when If-Modified-Since header is NOT set (example, on first request on bridge instance)

n should also be 0 in CLI mode.

I would suggest just to return 304 Not modified without adding any cached data, which may not exist. Sure, it must be returned if If-Modied-Since is set.

It's probably best to return an error if cached data doesn't exist and 304 Not Modified if it does, unless If-Modified-Since is set, in which case your suggestion applies.

There is currently a hard limit of 24 hours though, so bridges with a cache duration of higher than 24/n hours will report issues earlier. Also, bridges with low cache duration will report very frequently.

Maybe the report queue should be based on a combination of time and length. For example:

If the last successful bridge request was more than 24 hours ago and at least n failed requests were registered, then report an error.

@logmanoriginal logmanoriginal mentioned this issue Mar 2, 2019
Closed
This was referenced Mar 22, 2019
Closed
Closed
Merged
This was referenced Jun 21, 2019
Merged
Closed
Closed
Closed
This was referenced Jun 28, 2019
Closed
Closed
Closed
Closed
Closed
Closed
logmanoriginal added a commit that referenced this issue Oct 31, 2019
@logmanoriginal
core: Add an option to return errors in different formats (#1071)
e8536ac 
Bridge errors are currently included as part of the feed to
notify users about erroneous bridges (before that, bridges
silently failed).

This solution, however, can produce a high load of error
messages if servers are down (see #994 for more details).

Admins may also not want to include error messages in feeds
in order to keep those kind of problems away from users or
simply to silently fail by choice.

This commit adds a new configuration section "error" with
one option "output" which can be set to following values:

"feed": To include error messages in the feed (default)
"http": To return a HTTP header for each error
"none": To disable error reporting

Note that errors are always logged to 'error.log' independent
of the settings above.

Closes #1066
logmanoriginal added a commit that referenced this issue Oct 31, 2019
@logmanoriginal
core: Add an option to suppress error reporting (#1179)
1022b5f 
Error reporting currently takes place for each error. This can result
in many error messages if a server has connectivity issues (i.e. when
it re-connects to the internet every 24 hours).

This commit adds a new option to the configuration file to define the
number of error reports to suppress before returning an error message
to the user.

Error reports are cached and therefore automatically purged after 24
hours. A successful bridge request does **not** clear the error count
as sporadic issues can be the result of actual problems on the server.

The implementation currently makes no assumption on the type of error,
which means it also suppresses bridge errors in debug mode. The default
value is, however, set to 1 which means all errors are reported.

References #994
This was referenced Dec 1, 2019
Closed
Closed
infominer33 pushed a commit to web-work-tools/rss-bridge that referenced this issue Apr 17, 2020
@logmanoriginal
core: Add an option to return errors in different formats (RSS-Bridge…
59cc439 
…#1071)

Bridge errors are currently included as part of the feed to
notify users about erroneous bridges (before that, bridges
silently failed).

This solution, however, can produce a high load of error
messages if servers are down (see RSS-Bridge#994 for more details).

Admins may also not want to include error messages in feeds
in order to keep those kind of problems away from users or
simply to silently fail by choice.

This commit adds a new configuration section "error" with
one option "output" which can be set to following values:

"feed": To include error messages in the feed (default)
"http": To return a HTTP header for each error
"none": To disable error reporting

Note that errors are always logged to 'error.log' independent
of the settings above.

Closes RSS-Bridge#1066
infominer33 pushed a commit to web-work-tools/rss-bridge that referenced this issue Apr 17, 2020
@logmanoriginal
core: Add an option to suppress error reporting (RSS-Bridge#1179)
1763545 
Error reporting currently takes place for each error. This can result
in many error messages if a server has connectivity issues (i.e. when
it re-connects to the internet every 24 hours).

This commit adds a new option to the configuration file to define the
number of error reports to suppress before returning an error message
to the user.

Error reports are cached and therefore automatically purged after 24
hours. A successful bridge request does **not** clear the error count
as sporadic issues can be the result of actual problems on the server.

The implementation currently makes no assumption on the type of error,
which means it also suppresses bridge errors in debug mode. The default
value is, however, set to 1 which means all errors are reported.

References RSS-Bridge#994
@forenta forenta mentioned this issue Dec 28, 2021
Closed
@dvikan
Copy link
Contributor

dvikan commented Sep 12, 2023

I think this was mostly fixed by Configuration::getConfig('error', 'report_limit').

@dvikan dvikan closed this as completed Sep 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@logmanoriginal logmanoriginal

Labels
Need-Info Additional information required New-Feature This is a new feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dvikan @logmanoriginal @em92