statics: link auto-provisioned tigris bucket to its app#4827
Open
statics: link auto-provisioned tigris bucket to its app#4827
Conversation
FindBucket was calling the top-level addOns(type: tigris) query, which returns every tigris add-on the caller can see across every org and then filters client-side by org + metadata. For accounts with a lot of tigris add-ons this stalls `fly apps destroy` (and `fly apps move`). Use Organization.addOns(type:) via a new ListOrganizationAddOns query so we only transfer the relevant org's add-ons. Metadata-based app matching stays the same, since existing statics buckets are not linked by app_id.
Two changes, one motivation — stop dragging every tigris add-on through
statics bucket lookups:
* ensureBucketCreated now passes AppName to ProvisionExtension so web's
create_add_on mutation populates add_ons.app_id. New buckets are
linked by FK rather than only by the staticsMetaKeyAppId metadata
pointer.
* FindBucket now tries GetAppWithAddons (app-scoped) first and falls
back to the org-scoped ListOrganizationAddOns query only if no match
is found. Both paths verify the staticsMetaKeyAppId pointer so a
user-provisioned tigris add-on on the same app is not mistaken for a
statics bucket. Legacy buckets (created before the first change)
still resolve via the fallback without any backfill.
The Bucket return type moves from a generated type alias to a small
local struct so both code paths can feed into it cleanly.
5045b48 to
572a73d
Compare
5 tasks
golangci-lint's nlreturn linter flagged the bare `return &Bucket{...}`
after the guard. Add the blank line it wants.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
statics.ensureBucketCreatednow passesAppNamewhen provisioning the tigris bucket so web'screate_add_onmutation populatesadd_ons.app_id(internal/command/deploy/statics/addon.go). New buckets are linked by FK, not just by thestaticsMetaKeyAppIdmetadata pointer.statics.FindBucketis now tiered: it triesGetAppWithAddons(app-scoped) first and falls back toListOrganizationAddOns(the org-scoped query from fix(statics): scope FindBucket to the app's org #4826) only if no match is found. Legacy buckets created before the FK link still resolve via the fallback, no backfill needed.staticsMetaKeyAppIdmetadata pointer. A user-provisioned tigris add-on that happens to be attached to the same app viafly ext create tigriswill not be mistaken for a statics bucket and will not be touched byfly apps destroy.Bucketmoves from a generated-type alias to a small local struct so both GraphQL paths can feed into it.Why stacked / why in one PR
The user explicitly asked for the backwards-compatible app-scoped lookup in this PR: "we can assume we're not backfilling so both should work, new stuff should work better." Keeping the FK write and the FK read in the same change means we never ship a flyctl version that writes the link but doesn't read it (or vice versa), and the legacy fallback is always present.
Behavior change worth calling out
extensions.ProvisionExtensionerrors with "already exists for app" whenAppNameis set and the app already has any tigris add-on (internal/command/extensions/core/core.go:74-87). Previously, withAppNameempty, statics could silently create a second tigris bucket alongside a user's manually-provisioned one. Now it will refuse. That seems like the better behavior — there's no sane way for statics to share a bucket with a user-owned tigris — but reviewers should confirm.Test plan
go build ./...(passes locally)go vet ./internal/command/deploy/statics/... ./internal/command/apps/... ./gql/...(passes locally)fly ext list --app <name>(proves app_id is set).FindBucket's app-scoped path hits).fly apps destroy <app>— confirm the statics bucket is still cleaned up.fly apps destroystill finds and removes it via the org-scoped fallback.fly apps destroyreturns quickly on apps that do not have a statics bucket (the app-scoped query short-circuits before the fallback ever runs).