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

Handle errors in fetching RSS feeds more gracefully #604

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

chvp
Copy link
Collaborator

@chvp chvp commented Jan 27, 2025

Fixes #180.

screenshot_2025-02-01-143123
screenshot_2025-02-01-143147

@chvp chvp self-assigned this Jan 27, 2025
@chvp chvp added the enhancement New feature or request label Jan 27, 2025
@chvp chvp force-pushed the feat/rss-fetch-errors branch 5 times, most recently from 8bb0928 to bac2602 Compare February 1, 2025 13:21
Comment on lines +27 to +30
--color-green: green;
--color-grey: grey;
--color-orange: orange;
--color-red: red;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't even try, because I assume you will have a stronger opinion than me 😉

@chvp chvp force-pushed the feat/rss-fetch-errors branch from bac2602 to 3491868 Compare February 1, 2025 13:28
@chvp chvp requested a review from robbevp February 1, 2025 13:30
@chvp chvp marked this pull request as ready for review February 1, 2025 13:30
@chvp chvp force-pushed the feat/rss-fetch-errors branch from 3491868 to 650b595 Compare February 1, 2025 13:30
Copy link
Owner

@robbevp robbevp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This already looks good. I think my biggest issue is the way we show the status: I would try an icon rather than relying on color for meaning

Comment on lines +53 to +64
def error=(error_text)
self.latest_error = error_text
self.error_count = if error_text.present?
error_count + 1
else
0
end
end

def reset_error
self.error = nil
end
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since both of these methods are private, I think we can only use error= if there is an error, making the code a lot easier:

Suggested change
def error=(error_text)
self.latest_error = error_text
self.error_count = if error_text.present?
error_count + 1
else
0
end
end
def reset_error
self.error = nil
end
def error=(error_text)
self.latest_error = error_text
self.error_count = error_count + 1
end
def reset_error
self.latest_error = nil
self.error_count = 0
end

save!
end

def should_refresh?
error_count < 5
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm worried that 5 might be too few if a server has some outage. Maybe we make this limit a bit higher?

EDIT: Wrote this before I realised that we don't yet handle server-errors here. If we don't than 5 is certainly enough

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might also be good to place this value in a const at the top of the model

Comment on lines +34 to +35
rescue Net::HTTPClientException => e
self.error = e.message
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we want to handle server errors here as well? In RefreshRssFeedJob I added a few errors that would be discarded, but I think it would be better to handle those here as well
We could also do that in a next PR

@@ -27,6 +27,9 @@ en:
next: "Next"
previous: "Previous"
nav_pagination_label: "Entry pagination"
rss_feed:
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
rss_feed:
rss_feeds:

This would be more consistent with the other keys

@@ -0,0 +1,22 @@
.subscription__status {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a __status element, means that we must have a subscription block somewhere that this element is a descendant of. Since this status lives on its own, it can just be .subscription-status

# frozen_string_literal: true

module SubscriptionsHelper
def subscription_status_info(subscription)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you create a component for this status (fe. SubscriptionStatusComponent), we can place this helper logic and the view that uses it close together (and we can test it more easily)

<%= content_tag :td, class: 'table__cell' do %>
<%- if subscription.refreshable? %>
<%- status_info = subscription_status_info(subscription) %>
<i class="subscription__status <%= status_info[:class] %>" aria-label="<%= status_info[:label] %>" />
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not fully convinced that colored dots are the right solution here. While we cover screenreaders with the aria-label, the color itself might be unclear to a user (let alone someone with some form of color-blindness).
Maybe we can use icons to indicate the special statuses (warning, error and not yet fetched)? Since we don't show anything for newsletters it would be consistent to render nothing if everything is ok

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Rss feeds that recurringly return errors should warn the user
2 participants