fix(website-builder): invalidate redirect cache on type change, clarify the choice in Admin

[adrians5j]

Found while investigating why a Permanent → Temporary change appeared to have no effect. Two related problems, both about redirectType.

1. Type changes never invalidated the CDN cache

RedirectAfterUpdateHandler decided whether to flush CloudFront by diffing the old and new record:

// Invalidate cache if any redirect-related field changed or isEnabled changed
if (
    redirect.redirectFrom !== original.redirectFrom ||
    redirect.redirectTo !== original.redirectTo ||
    redirect.isEnabled !== original.isEnabled
) {

redirectType was absent, so the comment was wrong. It is not an incidental field — ActiveRedirectRestMapper.toDto maps it directly to permanent, one of only four values /wb/redirects returns, and the one that decides 308 vs 307.

That response is served with Cache-Control: public, max-age=31536000. The long TTL is deliberate: writes are supposed to flush the CDN via the cloudfrontInvalidateCache task. So changing only the type wrote to the database and then served stale data for up to a year.

What made this particularly hard to spot is that every other field change invalidates within seconds, so the system trains you to expect edits to take effect immediately.

Adds the missing comparison, and rewrites the comment to state the actual invariant — this list must track ActiveRedirectRestMapper.toDto plus isEnabled (which decides whether a redirect appears in the response at all).

2. Admin gave no indication the choice was consequential

"Permanent" produces a 308, which browsers cache indefinitely and keep following even after the redirect is repointed or deleted. There is no way to recall it from a browser that has already seen it. The dialog offered two bare labels with nothing to distinguish them.

Adds a tooltip via .help() (markdown-rendered, so the two options are separate paragraphs):

Temporary — browsers check with the server on each visit, so you can change or remove this redirect later.

Permanent — browsers remember it indefinitely and may keep redirecting even after you change or delete it.

Deliberately no status codes in the copy — "308" tells an editor nothing; the consequence is what they need.

Also changes the default from permanent to temporary. The option you get by not choosing shouldn't be the one you can't undo. Flagging this explicitly as the reviewable decision here: the counter-argument is that Permanent is the SEO-correct choice for a genuine move and probably the common case, so the default nudges users toward the weaker option. I lean toward recoverable-by-default, but it is a product call.

defaultValue only applies when no value is set, and EditRedirectPresenter populates from the stored record, so existing redirects keep their saved type. Only newly created ones are affected.

Follow-up, not in this PR

InvalidateRedirectsCacheUseCase triggers cloudfrontInvalidateCache, a task defined in api-file-manager-s3. Website Builder borrowing File Manager's task is an undeclared cross-package dependency: if that package isn't registered, the task id doesn't exist and every redirect invalidation fails. Silently — InvalidateRedirectsCacheUseCase returns Result.fail, but all three redirect event handlers await it and discard the result. Worth either giving WB its own task or extracting a shared one, and stopping the handlers from swallowing the failure.

Test plan

• yarn adio, yarn lint, yarn format, yarn webiny sync-dependencies
• api-website-builder and app-website-builder both build
• Edit a redirect's type only, confirm a CloudFront invalidation is created and /wb/redirects reflects the new permanent value
• Confirm the tooltip renders with both paragraphs in the Create and Edit dialogs
• Confirm a newly created redirect defaults to Temporary and existing ones keep their stored type

Manual — RedirectAfterUpdateHandler has no automated coverage.

🤖 Generated with Claude Code