feat(feed): allow per-feed refresh interval override

[ChrisJr404]

Closes #412.

Description

Adds an optional refresh_interval_minutes column on feeds. When set, it overrides the global polling frequency for that feed only. NULL (the default) keeps the existing behaviour, so the migration does not disturb existing installations.

The override is honoured by Feed.ScheduleNextCheck. The HTTP refresh delay (RSS TTL, Retry-After, Cache-Control, Expires) is still applied as a floor, so a small override cannot be used to ignore a server's explicit back-off.

Motivation

Issue #412 (44+ thumbs-up, multi-year ask) reports that some users want to refresh certain feeds more often than the global POLLING_FREQUENCY (e.g. fast news, status pages) while keeping a longer interval for others (e.g. arXiv, blogs that 429 if you fetch them too aggressively). Today everything moves at one global rate, which leads to either missed updates or rate-limit bans depending on which way the user tunes the global value.

The earlier attempt in #949 was closed in 2021, partly because at that point per-user polling was tangled with multi-user semantics. Each feeds row already belongs to a single user_id, so a per-row override is well-defined and does not require touching the multi-user feed-fetching design at all.

Changes

• Database: new refresh_interval_minutes integer column on feeds, NULL by default, with a CHECK constraint preventing values < 1. Added as a fresh migration step at the end of internal/database/migrations.go.
• Scheduler: Feed.ScheduleNextCheck honours the override when set. When NULL or zero, the existing global scheduler logic runs unchanged.
• REST API: model.Feed, FeedCreationRequest and FeedModificationRequest gain a refresh_interval_minutes field. On modification, sending 0 clears the override; omitting the field leaves it unchanged. Mirrored in client/model.go so existing Go consumers work too.
• UI: Edit Feed page exposes a Refresh interval (minutes) number input with help text. 0 (or empty) means "use the global default".
• Validation: value must be between MinFeedRefreshIntervalMinutes (5) and MaxFeedRefreshIntervalMinutes (10080, one week). The floor prevents a user from accidentally pointing a tighter interval at a publisher than the configured global minimum.
• i18n: new error.feed_invalid_refresh_interval, form.feed.label.refresh_interval_minutes and form.feed.help.refresh_interval_minutes keys added to all 22 translation files (English text used as a placeholder for the non-English files; happy to drop those if maintainers prefer to add them in a follow-up).

Testing

• go build ./..., go vet ./... and go test ./... all clean.
• New unit tests in internal/model/feed_test.go:
  • TestFeedScheduleNextCheckRefreshIntervalOverride exercises the basic override.
  • TestFeedScheduleNextCheckRefreshIntervalOverrideRespectsRefreshDelay confirms that a Retry-After longer than the override still wins.
  • TestFeedScheduleNextCheckRefreshIntervalOverrideIgnoresGlobalCap confirms the override is not clamped by the global round-robin maximum.
  • TestFeedScheduleNextCheckRefreshIntervalNilFallsBackToGlobal and ...ZeroFallsBackToGlobal confirm the existing scheduler runs unchanged when the override is unset.
  • Three TestFeedModificationRequestPatch* cases cover set / clear (zero) / leave-alone (nil) semantics.
• internal/validator/feed_test.go covers the bounds check.
• internal/api/api_integration_test.go adds TestUpdateFeedRefreshInterval, which drives create -> read (must be nil) -> set 120 -> read back -> clear with 0 -> attempt to set 1 (must be rejected) through the real HTTP API.

Breaking changes

None. The new column is NULL by default; the API field is *int so existing clients that don't send it continue to work unchanged.

Related issues

• Closes [Feature request] Fresh frequency setting for single feed #412
• Earlier attempt: Fresh frequency setting for a single feed #949 (closed 2021-07-05)

[jvoisin]

A dumb issue with allowing users to set their own refresh rates is that this allows someone to set a super-short one, getting the IP address of the miniflux instance blacklisted/429 for the other users :/

[ChrisJr404]

Fair concern. The PR has two protections that should cover the abuse case:

1. The override is clamped between 5 and 10080 minutes (validated in internal/validator/feed.go). 5 minutes is the same floor that protects against accidental misconfig elsewhere in the codebase. There is also a test that an attempted 1-minute override is rejected at the API layer.
2. Even when the override says "5 minutes", Feed.ScheduleNextCheck still applies the HTTP refresh delay as a floor, so if a server sent Retry-After: 3600 or a long Cache-Control: max-age, the override does not override that. That part is covered by the RespectsRefreshDelay test.

So a hostile user setting the shortest legal value (5 min) on a feed whose origin returns Retry-After: 6h would still wait 6 hours between fetches per the server hint.

Happy to also add a per-instance setting if you would prefer the floor to be operator-configurable rather than hardcoded to 5. Let me know.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within 14 days.

[fguillot]

Few observations:

• refresh_interval_minutes is accepted and validated on feed creation, but never copied from FeedCreationRequest to the parsed feed before persistence, so the requested value is silently discarded. The integration test only covers creation without an override.
• Unless I’m missing something, this cannot refresh feeds faster than POLLING_FREQUENCY, since feedScheduler only checks next_check_at on each polling tick. With POLLING_FREQUENCY=60 and an override of 5, the feed still refreshes roughly hourly. The scheduler cadence needs to be decoupled from the default feed interval.