Nova Card Rss News Laravel Package

Product Decisions This Supports

• Whether to keep scheduled feed warming in-house or buy it. The core value here is a boring, correct scheduler job: refresh a set of third-party feeds into cache on a cron. If that is on your roadmap as internal plumbing, this package is a candidate to replace bespoke try/catch-around-a-loop code that someone wrote once and nobody owns.
• Alert-fatigue and on-call policy. Prior to this release, a single unreachable publisher caused nova-rss:warm to exit 1, which the scheduler surfaced as Scheduled command [...] failed with exit code [1] — paging a human and filing an error-tracker ticket — while the cache was warm everywhere else. The new default (success if any source warmed; failure only when every source is down) changes the signal from "a stranger's server hiccuped" to "our network or configuration is broken," which is the failure you actually want a human to act on. This is a paging-policy decision as much as an engineering one.
• Build-vs-buy scope. --strict exists specifically so a CI/CD or ingestion pipeline that wants all-or-nothing can keep it. That means the package can serve two audiences (resilient dashboards vs. strict pipelines) without a fork — a point in favour of buying rather than writing two behaviours internally.
• Observability roadmap. Per-source failures are now logged with the source key and error message. This exists because the scheduler captures the exit code and discards stdout/stderr — so without it, "which publisher went down?" was unanswerable. If per-source health is on your dashboard roadmap, treat this log line as the interim answer and nova-rss:check as the health endpoint; richer per-source reporting is a gap you may need to fill yourself.
• Use cases it fits: a Nova/Laravel admin surfacing aggregated publisher content, a "latest from our partners" widget, any read-path that must not block on an external feed at request time.
• Release-hygiene risk on the vendor side. 3.1.1 was tagged with this work sitting uncommitted in the working tree and was described as a documentation release; 3.2.0 is the documentation of what actually shipped. Packagist cannot move a published version, so the code in 3.1.1 and 3.2.0 is effectively the same. This is not a functional problem, but it is a supply-chain and changelog-integrity signal to weigh if you pin versions for audit or compliance reasons. Pin to 3.2.0 (or later) so your lockfile references a commit whose notes match its contents, and rely on the test suite — 109 tests / 560 assertions, PHPStan clean — rather than on the 3.1.1 notes.

When to Consider This Package

Adopt when:

• You have multiple external RSS/Atom sources you do not control and need them cached ahead of request time on a schedule.
• You are on Laravel with the scheduler (and plausibly Nova, given the package name) and want warming as a first-class artisan command rather than ad-hoc code.
• You want the default to be tolerant of partial upstream failure — the common case for content aggregation — while retaining an opt-in strict mode for pipeline use.
• Your team would otherwise rebuild warm/check/log-per-source themselves; the delta between this and hand-rolled is small in effort but the failure semantics are the part people get wrong.

Look elsewhere or proceed with care when:

• You need a full ingestion pipeline — parsing into models, dedupe, retries with backoff, per-source timeouts and concurrency, queue fan-out. This package warms a cache; it is not an ETL layer, and the release notes indicate per-source error handling is log-and-continue, not retry.
• You require per-source SLAs or alerting granularity beyond a log line — there is no structured per-source metric here, and nova-rss:check is described as unchanged, i.e., health reporting at the whole-command level.
• Your pipeline genuinely needs all-or-nothing semantics and you cannot adopt --strict immediately — you are fine on this release, but confirm the flag is wired into your job definition, not just available.
• Vendor release discipline is a hard gate for your org. The 3.1.1 tagging episode is a process smell worth a conversation before you depend on this for anything customer-facing, even though the code quality signals (test count, static analysis) are good.
• Single-source or in-app-authored feeds — you do not need partial-failure semantics and could just read the feed directly with a short cache TTL.

How to Pitch It (Stakeholders)

To executives: This is a small dependency that keeps third-party content in our cache so pages stay fast, and the new version fixes a real operational cost: a partner's server going down used to page someone and open an error ticket even when everything on our side was fine. It now only alarms when our connectivity or configuration is actually broken, and it records which partner feed failed so we can answer that question without digging. Net effect is fewer false alarms and faster diagnosis, for the cost of a patch-level upgrade.

To engineering: Upgrade to 3.2.0 and wire it in. Behavioural change is in nova-rss:warm: exit zero if at least one source warms, non-zero only if all sources fail — so your existing scheduler job stops flapping on upstream timeouts. If any pipeline depends on fail-fast, add --strict to that invocation; that is the only migration action. Failed sources are now logged with key and error message, which matters because the scheduler swallows command output — check your log channel and retention are set for that volume. nova-rss:check is unchanged, so anything consuming it needs no change. Note 3.1.1 shipped this code but its notes called it a docs release; pin 3.2.0 so the lockfile matches the changelog, and treat the 3.1.1 notes as unreliable if anyone asks. Tests and PHPStan are green, so the risk here is low; the thing to actually review is whether our alerting should now key off "all sources down" rather than "command exited non-zero."