Suspendedremoval display in Frontend
All checks were successful
Build and Push / build (push) Successful in 1m28s

This commit is contained in:
2026-05-01 21:39:16 +02:00
parent a79d0defa4
commit b12bca8818
3 changed files with 82 additions and 12 deletions

View File

@@ -2,7 +2,10 @@ import { getSessionUser, canMutate } from "@/lib/session";
import { getTranslations, getFormatter } from "next-intl/server";
import { redirect } from "next/navigation";
import { listTenants } from "@/lib/k8s";
import { listActiveTenantRequestsByOrgId } from "@/lib/db";
import {
listActiveTenantRequestsByOrgId,
syncProvisioningStatuses,
} from "@/lib/db";
import {
listVisibleTenants,
canSeeInflightRequests,
@@ -160,6 +163,23 @@ export default async function DashboardPage() {
// Pending/in-flight requests are only shown to roles that can act on
// them. `user`-role customers see no request cards.
//
// syncProvisioningStatuses runs on every dashboard load: it walks
// active and provisioning rows and reconciles them against the
// current cluster state. Without this, the operator-initiated
// 60-day TTL deletion (Bug 37b) leaves the portal showing "Your
// assistant is ready!" cards for tenants that no longer exist —
// the operator deletes the CR, but the DB row stays at active=true
// until something updates it. Running the sync at every dashboard
// load keeps the portal eventually consistent with the cluster
// without needing a separate cron/job.
//
// Cost: one K8s GET per row in (active, provisioning) status. At
// pilot scale this is small; if it grows we'd cache or move to a
// periodic background job.
if (canSeeInflightRequests(user)) {
await syncProvisioningStatuses();
}
const orgRequests = canSeeInflightRequests(user)
? await listActiveTenantRequestsByOrgId(user.orgId)
: [];