Creating or deleting a wiki site holds the request open until the work finishes or a timer runs out #125

Open
opened 2026-09-21 07:18:37 +00:00 by cgalo5758 · 0 comments
Owner

What a person cannot do today

See a site operation while it is running. Creating, deleting, archiving or restoring a wiki site starts a durable workflow and the request waits on it for a few seconds; past that budget the member gets an honest "still working" answer and the list refreshes. Nothing persists the fact that an operation is in flight, so the list can only show sites that already exist, and the member learns the outcome by reloading.

What they should be able to do

See the site appear in a pending state the moment the operation starts, watch it settle when the workflow finishes, and see the failure on the row when it fails.

Why it matters

The wait budget is a guess about how long another system takes. Under it, a request is held for no reason; over it, the member is told nothing useful and is left to refresh until something changes.

Where

internal/integrations/fedwiki/web, the site handlers; internal/integrations/fedwiki/workflows, the activities that carry out the work.

Done when

In-flight site operations are persisted and rendered as states of their own in the member's list, the handlers return as soon as the workflow is started, and the wait budget is gone rather than merely shortened.

Migrated from status/issues.md at b7a0e15

## What a person cannot do today See a site operation while it is running. Creating, deleting, archiving or restoring a wiki site starts a durable workflow and the request waits on it for a few seconds; past that budget the member gets an honest "still working" answer and the list refreshes. Nothing persists the fact that an operation is in flight, so the list can only show sites that already exist, and the member learns the outcome by reloading. ## What they should be able to do See the site appear in a pending state the moment the operation starts, watch it settle when the workflow finishes, and see the failure on the row when it fails. ## Why it matters The wait budget is a guess about how long another system takes. Under it, a request is held for no reason; over it, the member is told nothing useful and is left to refresh until something changes. ## Where [`internal/integrations/fedwiki/web`](https://git.coopcloud.tech/wiki-cafe/member-console/src/commit/b7a0e15/internal/integrations/fedwiki/web), the site handlers; [`internal/integrations/fedwiki/workflows`](https://git.coopcloud.tech/wiki-cafe/member-console/src/commit/b7a0e15/internal/integrations/fedwiki/workflows), the activities that carry out the work. ## Done when In-flight site operations are persisted and rendered as states of their own in the member's list, the handlers return as soon as the workflow is started, and the wait budget is gone rather than merely shortened. Migrated from status/issues.md at b7a0e15
cgalo5758 added the
kind
enhancement
area/fedwikiarea/integrationsarea/member-ui
labels 2026-09-21 07:18:37 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#125