Description
We run a custom gatekeeper Worker (built per the custom-gatekeeper recipe) whose vendor both auto-provisions its account (VendorDescription.autoProvisionsAccount: true — it holds a deployment credential, so there is no OAuth flow to run) and advertises a resource pattern via getSupportedResources() (so blueprints can bind it).
On the Connectors page, this vendor's card appears twice in the "Available" section until the user adds the account, after which it collapses to a single card. Both cards open the same modal and behave identically, so this is cosmetic — but it reads as a broken deploy.
Observed on our pinned build (6478a144) and the composition looks unchanged on current main.
Steps observed
- Deploy a custom gatekeeper whose vendor sets
autoProvisionsAccount: true and returns a non-empty getSupportedResources().
- Bind it to the workshop as
GATEKEEPER_<NAME>; leave its ambient mode at the default ("optional") and do not add an account yet.
- Open the Connectors page: the vendor renders twice under "Available".
- Add the account via either card: it moves to "Connected" and the duplicate disappears.
Expected behavior
One card per vendor in "Available".
Where it appears to come from
workshop-frontend/src/routes/gatekeepers.tsx composes the section as availableVendors = [...vendors, ...addable] — the outputs of listGatekeeperVendors() (vendors with ≥1 enabled resource) and listAddableGatekeepers() (ambient vendors in "optional" mode with no account yet) — without de-duplicating by vendor id. listAddableGatekeepers()'s comment assumes the sets are disjoint ("ambient gatekeepers expose no resources"), which a vendor like ours breaks: auto-provisioned and resource-advertising.
If a dedup by id in the memo (keeping the resource-bearing entry) is the direction you'd want, we're happy to send that as a small PR per CONTRIBUTING.md — otherwise this is just the report.
Description
We run a custom gatekeeper Worker (built per the custom-gatekeeper recipe) whose vendor both auto-provisions its account (
VendorDescription.autoProvisionsAccount: true— it holds a deployment credential, so there is no OAuth flow to run) and advertises a resource pattern viagetSupportedResources()(so blueprints can bind it).On the Connectors page, this vendor's card appears twice in the "Available" section until the user adds the account, after which it collapses to a single card. Both cards open the same modal and behave identically, so this is cosmetic — but it reads as a broken deploy.
Observed on our pinned build (
6478a144) and the composition looks unchanged on currentmain.Steps observed
autoProvisionsAccount: trueand returns a non-emptygetSupportedResources().GATEKEEPER_<NAME>; leave its ambient mode at the default ("optional") and do not add an account yet.Expected behavior
One card per vendor in "Available".
Where it appears to come from
workshop-frontend/src/routes/gatekeepers.tsxcomposes the section asavailableVendors = [...vendors, ...addable]— the outputs oflistGatekeeperVendors()(vendors with ≥1 enabled resource) andlistAddableGatekeepers()(ambient vendors in "optional" mode with no account yet) — without de-duplicating by vendor id.listAddableGatekeepers()'s comment assumes the sets are disjoint ("ambient gatekeepers expose no resources"), which a vendor like ours breaks: auto-provisioned and resource-advertising.If a dedup by id in the memo (keeping the resource-bearing entry) is the direction you'd want, we're happy to send that as a small PR per CONTRIBUTING.md — otherwise this is just the report.