Schedule when a redirect rule starts applying

[MatsudaTsunenori]

An event page may need to send visitors to an “event ended” page from a specific date and time. For example, /events/summer should serve normally before 10 September 2026, 00:00 Asia/Tokyo, then redirect to /events/closed on subsequent requests. An editor should be able to prepare that change in advance.

The redirect form currently provides source, destination, status code, group, and an enabled switch. The API and stored rules have no activation time. This proposal adds an optional start datetime to the existing rule system.

Proposed behavior

• A rule with no start datetime keeps its current behavior.
• An enabled rule with a future start datetime is scheduled. It starts applying when the server time reaches that instant, including equality.
• Disabling a rule overrides its schedule. Re-enabling it preserves the datetime; a datetime already in the past makes it apply immediately.
• The admin shows Scheduled, Active, or Disabled, alongside the start datetime and the timezone used to display it. “Active” means eligible to match; another matching rule can still take precedence.
• The first version provides one start datetime per rule. End datetimes, recurring schedules, and multiple time slots for one source can be considered separately.

The event example would use a 302 redirect. Existing status-code defaults and saved rules would remain unchanged. The activation condition would also apply consistently to the existing terminal rule types, 410 and 451.

This controls requests to the configured URL. It does not unpublish the content, remove it from listings or APIs, close a submission endpoint, or navigate a page that a visitor already has open.

Datetime contract

Add an optional nullable startsAt field to redirect create/update inputs and return it in the redirect response. Store it as nullable starts_at in _emdash_redirects using a new forward migration. Existing rows receive null.

For updates, omission preserves the saved value; null clears the schedule. External inputs must identify an instant with Z or an explicit offset and be normalized to UTC before persistence. A new scheduling field can enforce this without tightening validation for existing content datetime fields.

The admin would convert between the site's configured timezone and UTC, showing the timezone next to the input. In the example, 2026-09-10 00:00 Asia/Tokyo becomes 2026-09-09T15:00:00.000Z. Changing the site timezone would change how a saved schedule is displayed, not its stored instant. Invalid or ambiguous local times need an explicit validation response rather than silent adjustment.

This relates to the datetime normalization discussion, #2777. Site-timezone conversion is a proposal there, not an agreed contract. This feature should settle its own input behavior without changing existing datetime widgets as a side effect.

Runtime approach

The existing redirect cache loads enabled rules together and indexes exact matches separately from compiled patterns. Keep future rules in that cache and evaluate their activation time for each request, using one captured server timestamp. Filtering out future rules when loading the cache would delay activation until the next refresh.

Apply the same eligibility check to exact matches, trailing-slash alternatives, pattern matching, and the repository matching helpers. A scheduled rule that is not due must allow matching to continue. Existing precedence and source uniqueness remain unchanged. Future enabled rules must also participate in loop validation, including when a disabled rule is enabled.

Slug-change redirects need a defined conflict policy: that path currently updates or deletes existing rules. A scheduled manual rule must not silently disappear or acquire a different destination. The implementation should surface the conflict for resolution before changing either rule.

This keeps activation independent of a scheduled job and preserves the current rule-loading query budget. A rule edit handled by another isolate still has the existing cache-propagation delay; request-time evaluation removes the time-boundary delay for rules already loaded, not the propagation delay for last-second edits.

Page caches and rollout

A cached page can prevent the redirect middleware from running. The first implementation investigation should establish the cache contract on a production build, including native Workers Caching via @astrojs/cloudflare/cache. EmDash's deprecated Cloudflare Cache API provider should not be the basis for the new design.

The preferred approach to validate is opting affected URLs out of page caching while the rule is enabled and invalidating previously cached responses on rule changes. Astro exposes path/tag invalidation; a wildcard source cannot simply be passed as a wildcard purge. This must cover existing pattern matches and prevent stale rule caches or in-flight renders from repopulating page caches after invalidation. Merely adding Cache-Control inside the redirect middleware is insufficient. If the provider cannot meet this contract, scheduling must require route caching to be disabled for the affected routes or remain unsupported in that configuration.

For scheduled responses, explicit cache controls should also prevent an earlier response from overriding a later edit or disable action. Independently configured upstream caches need to honor the policy; already stored browser responses and downloaded pages cannot be recalled by an origin purge. Production acceptance must include a page cached before the schedule was created. The cache integration is a design condition to prove, not a completed implementation.

The nullable column preserves existing rules, but it does not make scheduled rules compatible with old application code: an old reader sees enabled = 1 and ignores starts_at, so it can redirect early. The proposed rollout requires every serving instance to support scheduling before schedules are enabled. Before rolling back to an older release, scheduled rules must be disabled and caches invalidated. This operational constraint needs agreement before implementation, or the storage design needs a stronger compatibility boundary.

Verification

Tests should cover the instant before, at, and after activation with a warm rule cache; unchanged query counts; exact and pattern precedence; terminal statuses; create/edit/clear/disable/re-enable behavior; future loop detection; site-timezone round trips from browsers in other timezones; and invalid or ambiguous local times.

Migration tests should preserve existing data and cover retries after partial completion. Integration tests should cover SQLite, PostgreSQL, D1, and a production build with page caching enabled, including a cache entry created before the rule. The admin changes need Lingui strings and Arabic RTL verification.

Decisions requested

1. Is a single optional start datetime on existing redirect rules the right initial scope?
2. Should the input use the site timezone with UTC persistence, as proposed in Normalising `datetime` storage: canonical form, where to normalise, and the migration ordering constraint (#2773) #2777?
3. Is opting affected URLs out of page caching an acceptable first approach, with support conditional on proving invalidation and concurrent-write behavior?
4. Is the deployment restriction above acceptable, or should old-runtime-safe storage be required before adding scheduling?

This is a design proposal; no implementation or PR has been opened for it.

Drafted with AI assistance (OpenAI Codex).