A failed read of a FedWiki organization's last active-site change is treated as no change, on the sites card and in the swap #298

New Issue

2026-10-30T19:47:47Z

cgalo5758 commented

2026-10-30 19:47:47 +00:00

What happens

When an organization has more FedWiki sites than its plan allows, the extra sites are made read-only, and a member chooses which site stays active: by swapping with Keep active, or by archiving one site and restoring another. The swap cooldown (fedwiki-swap-cooldown, 30 days by default) limits how often that choice can change.

The cooldown check (cooldownMsgFor, internal/integrations/fedwiki/web/partials.go:614) reads the time of the organization's last change and treats any error of that read as "never changed" (:619-622), the answer it gives when no row exists. Two places use it:

The sites card (partials.go:369). A failed read drops the cooldown notice, so the card offers the change as available while the cooldown may forbid it, and nothing is logged.
The swap and the restore, which check again inside their transaction (internal/integrations/fedwiki/web/site_actions.go:494, :587). A failed read there is dropped, and the request fails on the transaction's next statement, so the member gets a generic error and the log records that later statement instead of the read that failed.

What should happen

Only "no row" means "never changed". Any other error is logged; the sites card shows its load error instead of offering the change, and the swap or restore answers as a failure caused by that read.

Where

internal/integrations/fedwiki/web/partials.go (cooldownMsgFor, checkSwapCooldown); internal/integrations/fedwiki/web/site_actions.go.

Why it matters

During a database fault, a member over the site limit is offered a change the cooldown may refuse, and the log hides the fault behind the error of a later statement.

### What happens When an organization has more FedWiki sites than its plan allows, the extra sites are made read-only, and a member chooses which site stays active: by swapping with Keep active, or by archiving one site and restoring another. The swap cooldown (`fedwiki-swap-cooldown`, 30 days by default) limits how often that choice can change. The cooldown check (`cooldownMsgFor`, `internal/integrations/fedwiki/web/partials.go:614`) reads the time of the organization's last change and treats any error of that read as "never changed" (`:619-622`), the answer it gives when no row exists. Two places use it: - The sites card (`partials.go:369`). A failed read drops the cooldown notice, so the card offers the change as available while the cooldown may forbid it, and nothing is logged. - The swap and the restore, which check again inside their transaction (`internal/integrations/fedwiki/web/site_actions.go:494`, `:587`). A failed read there is dropped, and the request fails on the transaction's next statement, so the member gets a generic error and the log records that later statement instead of the read that failed. ### What should happen Only "no row" means "never changed". Any other error is logged; the sites card shows its load error instead of offering the change, and the swap or restore answers as a failure caused by that read. ### Where `internal/integrations/fedwiki/web/partials.go` (`cooldownMsgFor`, `checkSwapCooldown`); `internal/integrations/fedwiki/web/site_actions.go`. ### Why it matters During a database fault, a member over the site limit is offered a change the cooldown may refuse, and the log hides the fault behind the error of a later statement.

cgalo5758 added the

kind

bug

area/fedwiki area/member-ui labels 2026-10-30 19:47:47 +00:00

cgalo5758 referenced this issue

2026-10-31 01:01:36 +00:00

A FedWiki row action or API delete answers a failed database read as "Site not found" #310

Sign in to join this conversation.