A link expiring within the next second crashes the redirect with a 500

Every single short URL that has an expires_at passes through a window, in its final second of validity, where the very next click 500s instead of either redirecting or cleanly 410ing. For a high-traffic link with a precise expiry (a flash-sale link, a time-boxed event RSVP, a one-time signed invite), this means real users get a server error at exactly the moment the link matters most, and it happens on every expiring link, every time, not as a rare edge case.

seconds_to_expiry = int((expires_at - datetime.utcnow()).total_seconds()); ttl = min(ttl, seconds_to_expiry); redis_client.setex(_cache_key(slug), ttl, payload). When a link expires in under 1 second, int(...) truncates seconds_to_expiry to 0 (or it is already negative by the time this executes).

1. Create a ShortURL with expires_at = datetime.utcnow() + timedelta(milliseconds=400).
2. client.get('/<slug>')
3. Observe: raises redis.exceptions.ResponseError: invalid expire time in setex, instead of returning 302.

This was a real, deliberate safety guard (max(1, ...)) that got removed -- min(ttl, seconds_to_expiry) alone has no floor, so it happily computes 0 or a negative number and hands it straight to Redis. Redis's SETEX (and EXPIRE/PEXPIRE generally) treats a non-positive expiry as a protocol-level error, not a "just expire it immediately" no-op -- so any code path that can produce ttl <= 0 needs to either floor it at 1, or skip caching entirely for that call.

Decide whether the fix should floor the TTL at a minimum of 1 second (simplest: still gets a cache entry, just a very short-lived one) or skip the set_cached_url call entirely when the link is about to expire (arguably more correct: no point caching something that is about to become invalid). Either way, redis_client.setex must never be called with ttl <= 0.