Problem
The current Resources page is using /api/monitor/resources directly.
That endpoint behaves like a global monitor overview, not a current-user visible resources feed. As a result, the page can surface:
- stale
stopped / destroying sandbox rows
- fallback monitor rows with no valid member binding (
未绑定Agent)
- historical sessions from other users or old cleanup residue
- missing or misleading provider detail for the sandbox the current user actually just created
This is why one-off cleanup helps temporarily but does not solve the product problem.
Why this is the wrong contract
These two concepts are different:
1. User-visible Resources
What the product page should show:
- only resources the current signed-in user can actually see or act on
- current visible leases / sessions
- current member ownership
- no historical monitor junk
2. Global monitor overview
What /api/monitor/resources is closer to:
- system-wide provider/session state
- background monitor snapshots
- fallback rows for leases/sessions even when the user-facing binding is gone
- useful for ops/admin/diagnostics, but not as the direct product data source
Proposed direction
Do not keep treating this as a filtering-only problem.
We should split the contracts:
- keep
/api/monitor/resources as the global monitor/admin/system overview
- add a dedicated user-scoped resources endpoint for the product page
- back the user-scoped endpoint with existing ownership/visibility logic (for example the same lease visibility rules already used by
sandbox_service.list_user_leases(...))
- make the
Resources page consume the user-scoped endpoint instead of the global monitor snapshot
Non-goal for PR #192
This should not be folded into PR #192.
PR #192 can still clean obvious garbage data when needed, but the contract split itself should land separately.
Acceptance criteria
Resources page no longer reads directly from the global monitor overview contract
- current user only sees their own visible resources/sandboxes
- stale
stopped / destroying / unbound historical rows do not appear in the product page
- newly created user-visible sandbox appears correctly in provider detail without depending on manual cleanup
- global monitor/admin view remains available separately for ops/debugging
Problem
The current
Resourcespage is using/api/monitor/resourcesdirectly.That endpoint behaves like a global monitor overview, not a current-user visible resources feed. As a result, the page can surface:
stopped/destroyingsandbox rows未绑定Agent)This is why one-off cleanup helps temporarily but does not solve the product problem.
Why this is the wrong contract
These two concepts are different:
1. User-visible Resources
What the product page should show:
2. Global monitor overview
What
/api/monitor/resourcesis closer to:Proposed direction
Do not keep treating this as a filtering-only problem.
We should split the contracts:
/api/monitor/resourcesas the global monitor/admin/system overviewsandbox_service.list_user_leases(...))Resourcespage consume the user-scoped endpoint instead of the global monitor snapshotNon-goal for PR #192
This should not be folded into PR #192.
PR #192 can still clean obvious garbage data when needed, but the contract split itself should land separately.
Acceptance criteria
Resourcespage no longer reads directly from the global monitor overview contractstopped/destroying/ unbound historical rows do not appear in the product page