brokered_connections: two reads carry no provider predicate (blocks the provider sunset flow)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
- Domain
- authorization, backend
Research direction
Start in server/src/plugins/store.ts at retireConnectionsFor and brokeredConnectionsFor, which lack the provider predicate the other selects use, and check the comments there that point to assertActivatable in server/src/index.ts. Done means both reads filter on the active broker provider and a test covering the offboarding sweep with a foreign-provider row shows it is neither revoked through the active broker nor audited as revoked. The fix is gated on the provider sunset flow, so confirm with maintainers before starting.
Written by the indexing model from the issue text.
Description
Two brokered_connections reads in server/src/plugins/store.ts carry no provider predicate, where the other 11 selects in that file all filter on the active broker:
retireConnectionsFor— the offboarding sweepbrokeredConnectionsFor— the settings-page read
Both are keyed (holder = 'person', userId) only.
Why it matters
retireConnectionsFor finds a person's connections and then calls the active broker's revoke() for each row it found. On a deployment holding rows from both providers, that is a revocation requested at the wrong vendor — which would not recognise the connection — while the audit row records vendorRevocationRequested about access that was never removed. A departed employee keeps live access and the record says otherwise.
brokeredConnectionsFor is milder: rows are resolved at the active provider's canonical URL, so another provider's connections are silently dropped from the settings page.
Why it is not urgent
Unreachable today. The startup activation refusal (assertActivatable, called from server/src/index.ts) refuses to boot when the configured provider differs from the provider on the existing rows, so a mixed deployment cannot start and neither read can see a foreign row.
Both sites were already unfiltered before the Arcade provider work began (base 7b1c20a) — this is pre-existing, not a regression.
Why it needs an issue rather than a fix now
The provider sunset flow is exactly the change that relaxes assertActivatable's refusal, and it turns both sites live. Whoever builds it must add the brokerProvider predicate to both reads. Both call sites now carry comments saying so and naming assertActivatable, but a comment is not a work item.
Also to correct
The design spec's inventory of provider-filtered sites lists the offboarding sweep among them. It is not one — the sweep has no provider filter at all. That line should be corrected when the sunset flow is specced.
Acceptance
- Both reads filter on the active broker provider.
- A test drives the offboarding sweep on a deployment holding a foreign-provider row and asserts it is not revoked through the active broker and not audited as revoked.
Context: filed from the Arcade provider PR (#770), which does not change either read.
- Dominant language
- TypeScript
- Stars
- 6.6k
- Forks
- 914
- Avg merge
- 17h 52m
- Merged PRs (30d)
- 155
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CopilotKit/OpenBot
-
Wrong key location at startupPossibly taken @charan-rathore claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 68/100
CopilotKit/OpenBot#800 ·
Maintainers usually reply within 1 day
-
setup-learning.ts fails on Windows with "spawn npx.cmd EINVAL"Possibly taken @Caldas claimed this 3 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
CopilotKit/OpenBot#792 ·
Maintainers usually reply within 1 day
-
Remote AG-UI Bots can't use the browser in chat: `computer_*` calls refused as "unavailable for this headless turn"Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 3/5 1-2 days Newbie friendliness 68/100
CopilotKit/OpenBot#804 ·
Maintainers usually reply within 1 day
-
Five out-of-subject findings from PR #770's tier-3 review (credential-revoking tests, single-user boot gate, OAuth client rotation, shared-use atomicity, untyped server/tests)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 4/5 Over a week Newbie friendliness 22/100
CopilotKit/OpenBot#786 ·
Maintainers usually reply within 1 day
-
server/tests leaks database connections: 55 files open a pool and never close itPossibly taken @adamsiwiec1 claimed this 3 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 70/100
CopilotKit/OpenBot#785 ·
Maintainers usually reply within 1 day
All issues in CopilotKit/OpenBot
Similar issues
-
The inspector never shows the instances field, so scaling out is unreachablePossibly taken @Mrkewl claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
xevrion/breakscale#96 ·
Maintainers usually reply within 4 days
-
Object parameters lose their structure when resources is enabledPossibly taken @asts-top claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
rossant/awesome-math#199 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
jaegertracing/jaeger-ui#4618 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
mifi/lossless-cut#3125 ·
Maintainers usually reply within 1 day