Consider allowing article deletion during feed refresh #51

New issue

Closed

opened 2026-07-13 10:19:20 -07:00 by serrebi · 1 comment

serrebi commented

2026-07-13 10:19:20 -07:00

Owner

This limitation creates a poor user experience: users frequently want to clean up read or unwanted articles while the app is updating content, but they are forced to wait until the refresh completes.

The goal is to evaluate whether this restriction can be removed without causing adverse effects due to architectural constraints. In most cases, deleting an article during a refresh should not lead to negative consequences, as the deletion affects only the local state of that specific article and does not interfere with the incoming feed data.

Preconditions

The application has one or more channels configured.
Channels takes a noticeable amount of time to refresh.

Steps to Reproduce

Start refreshing all feeds (or a subset of channels).
Open the article list for any channel.
Attempt to delete an article from the channel.

Actual Behavior

While the feed refresh is in progress, the application refuses to delete the article and displays the message:
"Articles cannot be deleted while feeds are refreshing. Try again after the refresh is complete."

Desired Behavior

The application should allow article deletion at any time, even when feeds are being refreshed. Deleting an article during a refresh should proceed normally and not cause any negative side effects.

Considerations

Assess whether the current blocking behavior is required by core architecture or is an implementation safeguard that can be relaxed.
Ensure that concurrent operations (refresh and deletion) do not lead to race conditions, data corruption, or inconsistent UI states.
If removal of the restriction is not fully possible, consider alternative approaches, such as:
- Allowing deletion of articles from feeds that are not currently being processed by the refresh routine.
- Implementing a queue for pending deletions that are applied once the refresh completes.
- Providing clearer feedback about why the operation is blocked and an estimated time until it becomes available.

Benefits

Improved user experience by removing unnecessary delays.
Greater flexibility for users who manage large numbers of feeds and want to curate their article list continuously.
More natural workflow alignment with user expectations (i.e., the ability to manage content independently of background sync operations).

BlindRSS currently blocks article deletion while feeds are being refreshed. If a user has many channels, the refresh process can take several minutes, during which time the user is unable to delete articles. This limitation creates a poor user experience: users frequently want to clean up read or unwanted articles while the app is updating content, but they are forced to wait until the refresh completes. The goal is to evaluate whether this restriction can be removed without causing adverse effects due to architectural constraints. In most cases, deleting an article during a refresh should not lead to negative consequences, as the deletion affects only the local state of that specific article and does not interfere with the incoming feed data. #### Preconditions - The application has one or more channels configured. - Channels takes a noticeable amount of time to refresh. #### Steps to Reproduce 1. Start refreshing all feeds (or a subset of channels). 2. Open the article list for any channel. 3. Attempt to delete an article from the channel. #### Actual Behavior While the feed refresh is in progress, the application refuses to delete the article and displays the message: `"Articles cannot be deleted while feeds are refreshing. Try again after the refresh is complete."` #### Desired Behavior The application should allow article deletion at any time, even when feeds are being refreshed. Deleting an article during a refresh should proceed normally and not cause any negative side effects. #### Considerations - Assess whether the current blocking behavior is required by core architecture or is an implementation safeguard that can be relaxed. - Ensure that concurrent operations (refresh and deletion) do not lead to race conditions, data corruption, or inconsistent UI states. - If removal of the restriction is not fully possible, consider alternative approaches, such as: - Allowing deletion of articles from feeds that are not currently being processed by the refresh routine. - Implementing a queue for pending deletions that are applied once the refresh completes. - Providing clearer feedback about why the operation is blocked and an estimated time until it becomes available. #### Benefits - Improved user experience by removing unnecessary delays. - Greater flexibility for users who manage large numbers of feeds and want to curate their article list continuously. - More natural workflow alignment with user expectations (i.e., the ability to manage content independently of background sync operations).

serrebi closed this issue

2026-07-13 10:40:20 -07:00

serrebi commented

2026-07-13 10:50:35 -07:00

Author

Owner

Fixed in v1.98.0. The block was a redundant safeguard: delete/restore already tombstone the article (so a concurrent refresh can't recreate it) and use their own short busy-timeout DB transactions — the same reasoning that already let permanent-delete (purge) run unguarded. Delete and restore now proceed at any time, even while a refresh is in progress.