AlmaLinux AppStream: enabled module stream past EOL with no warning from dnf

Short answer

No: dnf has no supported command or metadata field that exposes an AppStream stream's end-of-life date, and it will not warn when an enabled stream passes EOL. EOL detection must be scripted externally against AlmaLinux's published lifecycle data, keyed off the module name and stream you read from dnf module list --enabled.

Why dnf stays silent

The modulemd metadata that dnf consumes describes streams by name, version, context, and summary — it does not carry a queryable EOL field. You can confirm this on any AlmaLinux 9 host:

dnf module info nodejs:18
# Output shows Name, Stream, Version, Context, Profiles, Summary — no EOL.

Lifecycle dates live in AlmaLinux's release notes and lifecycle documentation, not in the repo metadata. So the practical pattern is:

1. Refresh metadata first — module data is only rebuilt on cache refresh, and a stale cache can hide lifecycle-relevant changes: dnf clean metadata && dnf makecache.
2. Enumerate enabled streams: dnf module list --enabled.
3. Compare each module:stream pair against the published AlmaLinux EOL schedule (a small lookup table in your provisioning/patching pipeline is enough).

What a stream switch actually does

dnf module switch-to nodejs:20 (or switch on older dnf builds) behaves like a targeted distro-sync: packages belonging to the old stream that are not satisfied by any other enabled stream or repository are removed, and the new stream's packages are installed. Packages that remain satisfiable non-modularly — for example via EPEL — are left in place, which can leave you with a mixed set.

To assess downtime risk in advance, always dry-run on the target host (or a clone):

dnf module switch-to nodejs:20 --assumeno

Read the transaction summary carefully: anything in the "Removing" list that a running service depends on is your downtime window. If a service's packages exist only in the old stream, plan the switch as a maintenance event rather than a background patch.

Finding orphans after a reset

dnf module reset nodejs disables the stream but does not remove its packages. Those RPMs simply stop receiving updates. Two ways to surface them:

dnf repoquery --unsatisfied
# or, with yum-utils installed:
package-cleanup --orphans

Treat the output as a candidate list, not a removal list. Third-party repos that satisfy the same dependencies non-modularly can make intentionally installed packages appear orphaned, so verify each entry against rpm -q --whatrequires and your own provisioning records before removing anything.

One caveat

This reflects established dnf/modularity behavior on RHEL-9-family systems; exact subcommand names (switch-to vs switch) vary slightly by dnf version, so check dnf module --help on your hosts. The EOL schedule itself is the piece you must keep current externally — no amount of dnf querying will substitute for it.