carlos / platform Public

What happens. objstore.Teardown empties and deletes the bucket named on the store record, then deletes the user, then deletes the record. If deleting the user fails, the record stays and the teardown is meant to be re-run. If another app is granted that bucket name in between, the re-run empties and deletes the new owner's bucket.

Reproduced on feat/carloku-paid-launch-20260916 at 4bbe94b6 with the in-memory provisioner:

1. An operator adopts bucket carlos-store-bab-titogo for app bac/other. That is the name bab/titogo would mint.
2. Teardown(bac/other) deletes the bucket, then DeleteUser fails. The record for bac/other still names the bucket.
3. bab/titogo is declared and granted. Its grant creates carlos-store-bab-titogo again and the app writes data.
4. Teardown(bac/other) is retried. It returns no error. The bucket is gone.

How likely. It needs an operator-adopted name that collides with a name another app mints, a failed revocation, and a grant of that name before the retry. Account names cannot contain a hyphen, so two minting apps cannot collide on their own. It predates the paid-launch branch.

Why it is filed separately. It was found while fixing a billing review finding about bucket ownership ledgers. It is a data-loss path, not a billing one, and it is not fixed on that branch.

A possible fix. Record on the store record that the bucket step is done before moving on to the user step, so a re-run skips straight to the user. Or have the re-run refuse when the bucket's ownership ledger shows another open owner. The ownership ledger now always has that information for stores torn down by the current code.