hotfix: handle unexpected panic situations when fetching feeds

[taevel02]

Hi.

I've noticed an unexpected error when fetching feeds after my contribution. You may remember the issue I mentioned in a previous PR, and I've fixed it. Below is the issue I was talking about.

The workaround is as follows

• Improved error handling: use the match syntax instead of unwrap() to return the appropriate error message when an error occurs, and use the Result type throughout the function to explicitly handle success and failure.

[taevel02]

As your pointed out, the feed_ids parameter passed to the get_most_recent_items function should only contain feeds with fetch_old_items false. This is an important change to minimize unnecessary database lookups and make the code more efficient.

In my initial implementation, I looked up all feed IDs, but through your review process, I realized that this approach was inefficient. Therefore, I changed the logic to only look up recent items for feeds with fetch_old_items false. This significantly improves the performance of the code and reduces unnecessary processing.

I've included this change in this commit, and I believe it improves the overall readability and efficiency of the code. I'll continue to monitor for any other impact this change may have, and make additional fixes if necessary.

Thank you for your review and I look forward to hearing more feedback.

[parksb]

What do you think about sorting the list at the end of the function?

+-- // Sort here    
|
|   for (feed, link, fetch_old_items) in pairs {
|       ...
|  
|       let filtered_items = ... // Now, you can make this variable immutable.
|  
|       // Since the `insert_new_items` function returns only inserted items, you can omit the empty checking.
|       inserted.extend(insert_new_items(db, feed, &filtered_items));
|   }
|      
+-> inserted.sort_by_key(|x| x.published_at);
    Ok(inserted)

[taevel02]

I think it's a good idea, but if you sort inserted at the end, if won't be sorted by latest.

[parksb]

Wait, do we need to sort the list at this point? The returned value inserted is only used for the notification (L27 of worker.rs), and the items stored in the database are sorted when it is read. Is there any reason to sort the filtered_items before inserting the value into the database?

I wrote this logic originally, but I think it might be worth considering now. Anyway, there's nothing wrong with the functionality, so let's merge it.