feat(tenant_consent): live progress page for the admin-consent flow (PPT-2032) - #441
Open
camreeves wants to merge 1 commit into
Open
feat(tenant_consent): live progress page for the admin-consent flow (PPT-2032)#441camreeves wants to merge 1 commit into
camreeves wants to merge 1 commit into
Conversation
…PPT-2032)
The consent callback previously held the browser for the full Graph
sequence - up to minutes when directory replication is slow - while the
tab still displayed Microsoft's consent page, indistinguishable from a
hang. It also risked browser/proxy timeouts (54s callbacks measured
against nginx's 60s default).
Now the callback spawns the work into a fiber and responds immediately
with a self-contained progress page (served by rest-api, no frontend
build involvement) that polls GET /admin_consent/flow/:id and shows:
- each step with pending/running/done/failed states
- live replication-retry detail ("Waiting for Microsoft to replicate
(attempt N)") via a new optional on_retry hook on
GraphReplicationRetry
- an elapsed timer, connectivity-loss notice, and a friendly error
panel on failure
- on completion: BroadcastChannel announcement (for any future
Backoffice listener) and redirect to the domain's authentication tab
(also fixes the double-slash redirect that landed on /domains/-/about)
Flow state lives in redis with a 15 minute TTL so any replica can
answer the polling. The flow id is an unguessable capability token and
the payload contains no secrets. Specs cover the state machine.
Contributor
Author
|
✅ Verified with the full browser flow on placeos-dev (
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #440 (base branch = its head, so this diff shows only the new work; retarget to master once #440 merges).
Why
After the admin clicks Accept, the browser waits on our callback for the whole Graph sequence — up to minutes in bad replication weather — while still displaying Microsoft's consent page. Indistinguishable from a hang, and it races nginx's 60s proxy timeout (we measured 54s callbacks).
What
The callback now spawns the Graph work into a fiber and responds immediately with a progress page — plain HTML/JS served by rest-api itself, zero frontend build involvement:
on_retryhook onGraphReplicationRetry/domains/-/about) and aBroadcastChannel("placeos_admin_consent")announcement so a future Backoffice listener can refresh the original tab — answering the open 2025 UX question without requiring a frontend change todayFlow state lives in redis (
RedisStorage.with_redis, 15 min TTL) so any replica answers the polling. The flow id is an unguessable capability token; the payload carries no secrets. Specs cover the state machine (step advancement, failure marking, unknown-flow 404 path).🤖 Generated with Claude Code