[BUG] Links do not expire after the set expire_after time.

[HDudz]

Describe the bug

Links do not expire after the set expire_after time. The link continues to redirect normally even after the expiration time has passed. This was tested both via the website UI and the API.

To Reproduce

Steps to reproduce the behavior:

1. Create a shortened URL with expire_after set to a time in the near future (e.g. 1-2 minutes ahead)
2. Wait until the expiration time passes
3. Visit the shortened link
4. Link still works and redirects normally — no expiration occurs

Via API:

POST https://spoo.me/api/url
Content-Type: application/json
Authorization: Bearer {API_KEY}

{
  "long_url": "https://www.google.com",
  "expire_after": "2026-05-11T18:10:00Z"
}

Expected behavior

After the expire_after datetime passes, visiting the shortened link should result in an expiration/error page, not a redirect to the original URL.

---

Screenshots

It's 20:18 in Poland so UTC+2, so 18:18 in UTC

Desktop (please complete the following information):

• OS: Windows
• Browser: Brave (also tested via API / Postman)

---

Additional context

Below is a timeline proving the link was accessed after the expiration time:

API response after creating the link:

{
    "alias": "fDoMIzA",
    "short_url": "https://spoo.me/fDoMIzA",
    "long_url": "https://www.google.com",
    "owner_id": "6a020ec35746cac54b1da051",
    "created_at": 1778522988,
    "status": "ACTIVE",
    "private_stats": true
}

Note: the API response does not include expire_after in the returned object, which may indicate the field is being silently ignored.

Stats after clicking the link:

{
    "summary": {
        "first_click": "2026-05-11T18:10:49.343000Z",
        "last_click": "2026-05-11T18:10:49.343000Z"
    },
    "short_code": "fDoMIzA"
}

The link was set to expire at 2026-05-11T18:10:00Z and was successfully accessed at 2026-05-11T18:10:49Z — 49 seconds after the expiration time — and redirected normally.

---

For Developers/Contributors/Self-Hosters:

Test Environment:

N/A — tested against the hosted production instance at spoo.me

---

Logs & Error Messages

No error messages were returned by the API. The link creation request returned HTTP 200 with "status": "ACTIVE".

Code Snippets

{
  "long_url": "https://www.google.com",
  "expire_after": "2026-05-11T18:10:00Z"
}

[Zingzy]

Thanks for sharing this @HDudz Will definitely look into this. Meantime any contributions are open 🙂

[HDudz]

[BUG] expire_after still not enforced after PR #246 (merged 2026-07-13)

Summary

PR #246 ("fix: enforce time-based URL expiry at resolve + derive effective status"),
which closed issue #185, was merged into main on 2026-07-13. As of 2026-07-20 ~23:19 UTC,
the production API (https://spoo.me) still does not enforce expire_after — neither at
redirect time nor in the derived status field.

Reproduction (fresh link, authenticated, server clock used throughout)

1. Create a link with expire_after 2 minutes in the future

POST https://spoo.me/api/v1/shorten
Authorization: Bearer spoo_****
Content-Type: application/json

{"long_url":"https://www.google.com","expire_after":"2026-07-21T01:17:00+02:00"}

Response (201 Created, server Date: Mon, 20 Jul 2026 23:14:49 GMT):

{"alias":"bjfGtTX","short_url":"https://spoo.me/bjfGtTX","long_url":"https://www.google.com","owner_id":"[redacted]","created_at":1784589288,"status":"ACTIVE","private_stats":true}

expire_after resolves to 2026-07-20T23:17:00Z.

2. After expiry, request the short link directly (raw HTTP status, no redirect following)

curl -I https://spoo.me/bjfGtTX

Result:

HTTP/1.1 302 Found
Date: Mon, 20 Jul 2026 23:18:09 GMT   <-- 69s after expire_after
Location: https://www.google.com

Expected per PR #246: 410 Gone. Actual: normal 302 redirect.

3. After expiry, check the derived status via the authenticated management endpoint

GET https://spoo.me/api/v1/urls?page=1&pageSize=1
Authorization: Bearer spoo_****

Result (server Date: Mon, 20 Jul 2026 23:18:59 GMT, 119s after expire_after):

{
  "items": [
    {
      "id": "6a5eabe99532a4d0526b0b0a",
      "alias": "bjfGtTX",
      "long_url": "https://www.google.com",
      "status": "ACTIVE",
      "created_at": "2026-07-20T23:14:48.995000Z",
      "expire_after": 1784589420,
      "total_clicks": 1,
      "last_click": "2026-07-20T23:16:19.877000Z"
    }
  ]
}

expire_after: 1784589420 = 2026-07-20T23:17:00Z. status is still "ACTIVE"
despite the endpoint being queried ~2 minutes after expiry — this field is supposed
to be effective_status, derived on every read per the PR description, not a stale
stored value.

Environment

• All timestamps above are taken from the Date: response header of spoo.me
  itself (Cloudflare/Caddy), not client clocks — ruling out any client-side
  timezone issue.
• Requests made via POST /api/v1/shorten and GET /api/v1/urls with a valid
  API key (Authorization: Bearer ...), so this is not the anonymous/legacy
  code path.
• expire_after was sent as ISO 8601 with explicit UTC offset (+02:00), matching
  the documented format.

Expected behavior (per PR #246 description)

resolve() now 410s past-expiry links on both the cache-hit and DB paths...
DTOs... answer from derived effective status so unvisited expired links read
EXPIRED everywhere.

Actual behavior

Past-expiry links continue to 302 redirect and report status: "ACTIVE"
even ~2 minutes after the configured expire_after, as timestamped by the
server's own Date: header.

[Zingzy]

@HDudz this would be taken live in the next week, which would be next week!

[HDudz]

Sorry for that, thought It's live. MB