Problem
file_provider_copies, added in #1666, keys a copy on (file_id, provider, provider_instance, credential_workspace_id). Those four identify the provider account a copy lives in today, because the configured instance and the workspace's organization are what select the credential.
They do not survive the credential changing. An organization that rotates its provider key to a different account, or a configured instance repointed at another account, leaves every row for that key naming a provider file ID the new account does not hold. Nothing invalidates the rows, so the reuse path keeps returning those IDs until each copy's own expiry passes, and every request that finds one fails at dispatch with the provider's own unknown-file error rather than through the files code.
The window is bounded by files_provider_upload_ttl_hours, one hour by default, and by the file's own expiry where one is set. It is not bounded where a deployment raises the TTL.
The same rotation also strands the copies themselves: once the credential is gone, nothing can delete what it uploaded, so #1487 cannot reach them either.
What the other design does
#1185 carries provider_account_generations with credential_source, credential_ref, generation and a status of active, retiring or retired, and binds each copy to a generation. A rotation opens a new generation, so a copy knows which account it is in and an old generation can be retired deliberately rather than discovered by failure. #1666 has no equivalent, by choice: keying on the credential identity would couple the files table to the provider-key model, which #1488 owns.
Proposal
Settle it as part of #1488's data-model question rather than in isolation, since the two designs answer it differently. Whatever shape wins needs to say:
- how a copy names the account it is in, in a way a rotation changes;
- what happens to copies of a retired generation: deleted deliberately, or left to expire;
- whether the reuse path revalidates, or whether a stale ID is allowed to fail at dispatch once.
A cheaper interim, if #1488 stays open: treat a dispatch failure that names an unknown provider file as a signal to drop the row, so the next request re-uploads rather than repeating the failure.
Acceptance
Part of #1470. Related: #1488, #1487, #1639.
Problem
file_provider_copies, added in #1666, keys a copy on(file_id, provider, provider_instance, credential_workspace_id). Those four identify the provider account a copy lives in today, because the configured instance and the workspace's organization are what select the credential.They do not survive the credential changing. An organization that rotates its provider key to a different account, or a configured instance repointed at another account, leaves every row for that key naming a provider file ID the new account does not hold. Nothing invalidates the rows, so the reuse path keeps returning those IDs until each copy's own expiry passes, and every request that finds one fails at dispatch with the provider's own unknown-file error rather than through the files code.
The window is bounded by
files_provider_upload_ttl_hours, one hour by default, and by the file's own expiry where one is set. It is not bounded where a deployment raises the TTL.The same rotation also strands the copies themselves: once the credential is gone, nothing can delete what it uploaded, so #1487 cannot reach them either.
What the other design does
#1185 carries
provider_account_generationswithcredential_source,credential_ref,generationand astatusofactive,retiringorretired, and binds each copy to a generation. A rotation opens a new generation, so a copy knows which account it is in and an old generation can be retired deliberately rather than discovered by failure. #1666 has no equivalent, by choice: keying on the credential identity would couple the files table to the provider-key model, which #1488 owns.Proposal
Settle it as part of #1488's data-model question rather than in isolation, since the two designs answer it differently. Whatever shape wins needs to say:
A cheaper interim, if #1488 stays open: treat a dispatch failure that names an unknown provider file as a signal to drop the row, so the next request re-uploads rather than repeating the failure.
Acceptance
Part of #1470. Related: #1488, #1487, #1639.