[api] Dead code: refresh_meta_cache is gated behind `if false`, plus unreachable meta cache-priming path

[JayDwee]

Severity

Low — dead code / confusing intent

Location

api/src/meta/guilds.rs:34-39 and refresh_meta_cache at api/src/meta/guilds.rs:114-137

Problem

pub fn setup(discord_bot: Arc<Client>) {
    info!("Spawning meta cache refresh task");   // logs even though nothing spawns
    if false {
        tokio::spawn(refresh_meta_cache(discord_bot));
    }
}

• The if false guard means refresh_meta_cache never runs, yet the "Spawning meta cache refresh task" info line still prints on every cold start (also duplicated in meta/mod.rs:19), implying a background task exists when it doesn't.
• refresh_meta_cache references get_current_user_guilds_prime_cache / get_guild_prime_cache (imported at meta/guilds.rs:2-5) — cache-priming variants that add complexity solely for this disabled path.
• The sleep math is also suspect: time.sub(Instant::now()) computes a negative-ish Duration (it's start - now, i.e. already elapsed, saturating to ~0) then adds 50s — the debug log claiming to wait computes it in the opposite direction. This would misbehave if ever enabled.

In a Lambda execution model a long-lived loop { sleep } background task generally can't run reliably between invocations anyway, so this may be the wrong pattern entirely.

Suggested resolution

Either delete setup/refresh_meta_cache and the *_prime_cache helpers if caching is handled by the #[cached] TTLs already on the get_* functions, or, if a warm cache is genuinely needed, move it to a scheduled invocation (EventBridge) rather than an in-process loop and remove the if false. At minimum, drop the misleading log line until the task actually spawns.

[JayDwee]

Investigated this. Confirmed the if false gate is real dead code (not a compile error — get_current_user_guilds_prime_cache / get_guild_prime_cache are legitimately auto-generated by the cached proc-macro from get_current_user_guilds / get_guild in api/src/discord.rs, via cached_proc_macro's <fn>_prime_cache codegen). Also confirmed the sleep-duration bug: time.sub(Instant::now()) computes elapsed time (not remaining time), so if this loop ever ran it would busy-loop closer to every 50s regardless of how long the refresh itself took.

Before picking a fix, I want to confirm intent, since the "Suggested resolution" in the issue offers two genuinely different directions and I don't want to guess wrong:

1. Delete meta::setup/guilds::setup, refresh_meta_cache, and the *_prime_cache call sites entirely, on the basis that caching is already handled by the #[cached] TTLs on get_current_user_guilds (180s) and get_guild (60s) — the background task would only be a minor warm-cache perf optimization, not a correctness requirement. This also sidesteps the fact that a long-lived in-process loop is a poor fit for the Lambda execution model this service runs in (api/src/main.rs dispatches to run()/run_local() via lambda_http).
2. Resurrect it: remove the if false, fix the sleep-duration math, and move the refresh to a scheduled Lambda invocation (e.g. EventBridge-triggered) instead of an in-process loop { sleep }, because a warm cache is actually wanted for some reason (e.g. reducing p99 latency on cold guild lookups, or avoiding Discord rate limits on bursty traffic).

Which direction is intended? If it's (2), that's more than a "fix the condition" change — it requires restructuring how the refresh is triggered (new Lambda entry point / EventBridge rule), so I'd want to scope that as its own follow-up rather than bolt it onto this bugfix. Happy to also just drop the misleading "Spawning meta cache refresh task" log line as a minimal stopgap in the meantime if that's useful, but wanted to confirm before touching the rest.

---

Generated by Claude Code

[JayDwee]

1, remove dead code and rely on cache macro