Forgetting Resources Deleted Outside Infrastream
Infrastream keeps a record of every resource it manages. When something is destroyed outside the platform — a project deleted in the console, a database dropped by hand — that record outlives the resource, and every run afterwards tries to reconcile something that is no longer there.
This guide covers how to clear those records, and the one situation that looks identical but where clearing them would be a serious mistake.
What you will see
Affected resources appear as stalled, not failed, with an error naming a provider rather than the resource:
postgres ClientManager not found in context —
resource not registered through a postgres provider
The stall is permanent. It will not clear on its own, and re-running will not help.
Why Infrastream cannot fix this by itself
To delete a resource, Infrastream needs the provider that manages it — a Postgres connection to drop a Postgres role, for example. When the database itself is gone, so is the connection. The platform can neither update the resource nor remove it.
It could simply drop the record. It deliberately does not.
Infrastream releases a record on its own only when it can prove the resource is gone — for instance, when the project containing it reports as deleted. That is evidence of absence.
A missing provider is not proof. It is equally consistent with a resource that still exists and was temporarily orphaned by a configuration change. Guessing wrong would abandon live infrastructure — still running, still billed, and no longer tracked by the only system that knew about it.
So the platform stops and waits for someone who knows which it is. You are the evidence it is missing.
Clearing the record
- Open the Infrastructure tab and select the stalled run.
- Choose the stalled resource. Where other stalls offer a fix, this one offers Forget this state entry.
- Read the resource path shown, and confirm the resource really is gone (see Check before you confirm).
- Tick "I have checked, and this resource no longer exists."
- Select Forget this entry.
What this does and does not do
| Does | Remove the record from the platform's live view of your infrastructure |
| Does | Keep a permanent entry in the run history showing what was forgotten, and by whom |
| Does not | Delete, modify, or touch anything in your cloud account |
Nothing here will look for the resource on your behalf. If it still exists, forgetting its record does not remove it — it only stops Infrastream from managing it.
Permissions
Only an administrator of the environment that owns the resource can forget a record. A production resource requires a production administrator; a development one does not.
Expect two passes
Resources inside a deleted container are usually orphaned by the same missing provider. When you forget a database, its roles and grants do not disappear with it — the next run reaches them directly, hits the same problem, and offers them individually.
A database with nine roles and fifty-nine grants takes two rounds: forget the database, run, then forget the rest. This is expected, and the confirmation message tells you how many dependents to expect.
You must be on the latest run
The option is only available on the most recent apply run. Each run builds its picture of your infrastructure from the previous one, so clearing a record anywhere else would be quietly undone. If the button is disabled, open the latest run.
Check before you confirm
This is the one case where forgetting causes real harm.
When a project's billing is unlinked, the project and everything in it still exist. Resources keep running and keep costing money. Infrastream simply cannot read them.
Forgetting those records is how live infrastructure becomes invisible to the only system that knows it is there.
The two situations look similar in a run summary and call for opposite responses:
| Resource deleted | Billing unlinked | |
|---|---|---|
| Does it still exist? | No | Yes |
| What the error says | ClientManager not found in context | PermissionDenied … check billing account |
| Shown as | Stalled | Failed |
| Offers "Forget this entry" | Yes | No |
| Still costing money? | No | Yes |
| What to do | Forget the record | Restore billing, or remove it from your manifests |
The platform will not offer the option for a billing problem, so you cannot trigger this by clicking. The risk is one of interpretation: a whole project's worth of resources failing at once looks like a deleted project whichever cause is behind it.
When in doubt, ask the project directly:
gcloud projects describe <project-id>
gcloud beta billing projects describe <project-id> # look for billingEnabled
A project that answers is not gone. Restore its billing or remove it from your manifests — do not forget its resources.
After forgetting
The stall disappears from the run, and the run's stalled count updates immediately. The next run stops attempting the resource.
The record remains in your run history permanently. Forgetting is not erasing: there is always an audit trail showing what was removed, when, and by whom.
Related
- Disaster Recovery and Rollback — recovering from deployments and data loss
- Database Point-in-Time Recovery — restoring data rather than clearing records