[parsonsmatt]

Summary

getGetMaxExpires cached its value behind a mkAutoUpdate worker on a 24-hour refresh cycle. Because the refresh interval is a full day, the worker thread lingers for up to 24h after its last use before it can notice it's idle and exit.

Constructing a YesodRunnerEnv per request — which test harnesses like hspec-yesod do — therefore accumulates dormant worker threads proportional to the request count. (The session date cacher and logger time cache don't have this problem: their mkAutoUpdate workers self-terminate quickly because their refresh intervals are seconds, which is also why clientSessionDateCacher's "closer" is already a documented no-op.)

The cached value is just formatTime of now + 1 year — a single cheap call. Caching it behind a thread is a premature optimization; runFakeHandler already computes it inline. This PR recomputes it on each call and drops the worker entirely.

getGetMaxExpires :: IO (IO Text)
getGetMaxExpires = pure getCurrentMaxExpiresRFC1123   -- was: mkAutoUpdate { ...updateFreq = 24h... }

Compatibility

No API changes — patch release (1.7.0.0 → 1.7.0.1):

• getGetMaxExpires :: IO (IO Text) — signature unchanged.
• yreGetMaxExpires field — unchanged.
• Both YesodRunnerEnv construction sites (mkYesodRunnerEnv, toWaiAppLogger) and any direct caller benefit automatically.
• Only other change: dropped the now-unused Control.AutoUpdate import in Dispatch.hs (the dependency stays — clientSessionDateCacher still uses it).

Behavior change: the max-expires timestamp now advances continuously instead of jumping once per day. It's a far-future (+1yr) value used for cache/expiry headers, so this has no practical effect.

Testing

cabal build yesod-core compiles clean. This unblocks per-request YesodRunnerEnv construction in test harnesses without leaking worker threads.

🤖 Generated with Claude Code