fix(e2e): use getByRole('checkbox') for reka-ui Checkbox + cookie scope fix#145
Conversation
When an API key has allowedProviders referencing a provider that no longer exists in the registry (stale ID), the update operation would fail with 'unknown provider(s)' error. Now validate_providers() has been replaced with filter_valid_providers() which silently removes unknown IDs instead of rejecting the entire operation. This allows users to edit API keys even when some provider references have become stale. Changes: - manage_api_keys.rs: filter_valid_providers() filters stale IDs - api_key_provider_validation.rs: updated 3 unit tests for new behavior - api-keys.spec.ts: added 5 new E2E tests for provider restrictions
…ordion When an API key has many providers configured (e.g., 500+), a flat checkbox list doesn't scale. This change groups providers by their providerKind and displays them in a collapsible accordion: - Each group shows: kind name, provider count, selected count - Groups are collapsed by default to reduce visual noise - Group-level checkbox allows select-all/deselect-all for a kind - Individual providers can still be toggled independently Before: flat list of 500+ checkboxes (unmanageable) After: accordion grouped by kind (e.g., Ollama Cloud: 500 providers)
…ovider test The reka-ui Checkbox uses a visually-hidden <input> with role="checkbox" on the visible button. The previous selector [data-testid^="provider-checkbox-"] targeted the wrapper, and setChecked() on it didn't trigger the @update:model-value event that updates the form state. Clicking the role=checkbox element (the visible button) correctly dispatches the events the reka-ui Checkbox listens for. Only uncheck if currently checked (data-state='checked') to avoid toggling wrong state. Also fixes a double-slash URL bug: ${DASHBOARD_URL}/api-keys became /dashboard//api-keys because DASHBOARD_URL already ends with /. Use ${DASHBOARD_URL}api-keys (no leading slash) for navigation. Cookie scope fix in global-setup: use explicit domain: 'localhost', path: '/' instead of url: DASHBOARD_URL — the latter would infer path /dashboard, blocking cookies from being sent to /api/* Vite-proxied routes. API_BASE_URL defaults to http://127.0.0.1:8081 (Docker proxy on macOS only forwards IPv4, localhost resolves to ::1 first causing ECONNRESET). DASHBOARD_URL keeps localhost since Vite dev server runs on localhost:4747. All 47 e2e tests pass (7 webkit skipped due to known CSRF Docker image issue). just ci-local: ALL PASSED (369s total)
|
Warning Review limit reached
More reviews will be available in 24 minutes and 46 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughBackend now filters unknown/stale provider IDs on API key create/update. Frontend groups providers by kind in an accordion UI with group-level checkboxes. E2E tests and Playwright global setup were updated and new tests validate provider-restriction create/edit/update/clear flows. Vite config adds BASE_PATH and sets dev port 4747. ChangesProvider restriction filtering and UI grouping
Sequence DiagramsequenceDiagram
participant User as User (UI)
participant ApiKeyForm as ApiKeyForm (frontend)
participant API as Backend API (manage_api_keys)
participant Registry as Provider Registry
User->>ApiKeyForm: select providers / submit create/update
ApiKeyForm->>API: POST/PUT create/update with allowedProviders
API->>Registry: request provider list via registry.providers()
Registry-->>API: respond with known provider IDs
API-->>ApiKeyForm: return created/updated ApiKey with filtered allowedProviders
ApiKeyForm-->>User: display grouped provider state and saved key info
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/rook/dashboard/e2e/api-keys.spec.ts`:
- Around line 553-560: The provider checkbox selector is using
input[type="checkbox"] which targets a visually-hidden input for reka-ui
Checkbox; change the lookup to use role-based selector like
getByRole('checkbox') or locator('[role="checkbox"]') so the interactive element
is targeted—update the
providersSection.locator('input[type="checkbox"]').first() usage (the
firstProvider variable) to use page.getByRole('checkbox').first() or
providersSection.getByRole('checkbox').first() and keep the same
visibility/check logic (await firstProvider.isVisible() then await
firstProvider.check()).
In `@apps/rook/dashboard/src/components/ApiKeyForm.vue`:
- Around line 308-331: The AccordionTrigger wrapper (component AccordionTrigger)
already renders a rotating ChevronDown, but ApiKeyForm.vue currently also
renders a manual <ChevronDown> inside the trigger div causing duplication and
non-rotation; remove the manual ChevronDown element from the AccordionTrigger
block in ApiKeyForm.vue (or alternatively move it into the trigger’s `#icon` slot
if you need a custom icon) so only the wrapper-controlled chevron is rendered
and rotation styles apply correctly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 628b6e38-7db8-4482-aa5e-8387ac194d52
📒 Files selected for processing (5)
apps/rook/dashboard/e2e/api-keys.spec.tsapps/rook/dashboard/e2e/global-setup.tsapps/rook/dashboard/src/components/ApiKeyForm.vuecrates/application/rook-usecases/src/manage_api_keys.rscrates/application/rook-usecases/tests/api_key_provider_validation.rs
| <AccordionTrigger class="py-2"> | ||
| <div class="flex items-center gap-2 w-full pr-2"> | ||
| <!-- Group-level select all checkbox --> | ||
| <Checkbox | ||
| :model-value="isKindGroupChecked(kind)" | ||
| :indeterminate="isKindGroupIndeterminate(kind)" | ||
| :data-testid="`provider-kind-checkbox-${kind}`" | ||
| @update:model-value="(checked: boolean | 'indeterminate') => { if (typeof checked === 'boolean') toggleKindGroup(kind, checked); }" | ||
| /> | ||
| <span class="text-sm font-medium"> | ||
| {{ getCatalogEntry(kind)?.displayNameKey | ||
| ? $t(getCatalogEntry(kind)!.displayNameKey) | ||
| : kind }} | ||
| </span> | ||
| <Badge variant="secondary" class="text-xs"> | ||
| {{ kindProviders.length }} | ||
| </Badge> | ||
| <!-- Show selected count --> | ||
| <span class="text-xs text-muted-foreground ml-auto"> | ||
| {{ kindProviders.filter(p => isProviderChecked(p.id)).length }}/{{ kindProviders.length }} | ||
| </span> | ||
| <ChevronDown class="h-4 w-4 text-muted-foreground shrink-0" /> | ||
| </div> | ||
| </AccordionTrigger> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
reka-ui AccordionTrigger default chevron icon customization
💡 Result:
In Reka UI, AccordionTrigger does not expose a dedicated “default chevron icon” prop to swap/override; instead, you customize the indicator by composing your own content inside AccordionTrigger. How to customize the chevron icon (recommended) - Put your own icon element inside AccordionTrigger (e.g., an Icon component) and style/rotate it based on the trigger’s state. - The official accordion docs show adding a chevron icon and rotating it when the trigger is open by targeting the AccordionTrigger’s data-state="open" attribute. Example (Vue) - Use a chevron icon (shown in the docs as radix-icons:chevron-down) inside AccordionTrigger: [1] - Rotate it when open via CSS targeting data-state="open": [1][2] CSS (matches the docs pattern).AccordionChevron { transition: transform 300ms; }.AccordionTrigger[data-state="open"] >.AccordionChevron { transform: rotate(180deg); } Notes - Reka UI components are “unstyled” primitives; styling (including the chevron/indicator) is your responsibility. The docs demonstrate customizing parts via class/data-state selectors. [3][2]
Citations:
- 1: https://reka-ui.com/docs/components/accordion
- 2: https://reka-ui.com/docs/guides/styling
- 3: https://reka-ui.com/
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# 1) Show surrounding snippet in the target file
FILE="apps/rook/dashboard/src/components/ApiKeyForm.vue"
echo "=== Context around AccordionTrigger (lines ~290-360) ==="
nl -ba "$FILE" | sed -n '290,360p'
# 2) Find all ChevronDown occurrences in the file
echo "=== ChevronDown occurrences ==="
rg -n "ChevronDown" "$FILE" || true
# 3) Check for any rotation logic in the file (data-state/open, rotate, transition)
echo "=== Possible chevron rotation styling in the file ==="
rg -n "data-state|rotate\\(|transition|ChevronDown|AccordionTrigger" "$FILE" || true
# 4) Search repo for any styling pattern targeting accordion trigger open state
echo "=== Repo-wide patterns: data-state open + chevron/accordion ==="
rg -n "AccordionTrigger|data-state=\"open\"|\\[data-state=\"open\"\\]|chevron|ChevronDown|rotate\\(180|rotate\\(\\-180|AccordionChevron" apps/rook/dashboard/src || trueRepository: dallay/cortex
Length of output: 175
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="apps/rook/dashboard/src/components/ApiKeyForm.vue"
echo "=== Context around AccordionTrigger (lines 290-360) ==="
cat -n "$FILE" | sed -n '290,360p'
echo "=== ChevronDown occurrences ==="
rg -n "ChevronDown" "$FILE" || true
echo "=== Possible chevron rotation styling in the file ==="
rg -n "data-state|\\[data-state=|rotate\\(|transition|AccordionChevron|ChevronDown" "$FILE" || true
echo "=== Repo-wide patterns for accordion chevron rotation ==="
rg -n "AccordionTrigger|data-state=\"open\"|\\[data-state=\"open\"\\]|AccordionChevron|ChevronDown|rotate\\(180|rotate\\(-180" apps/rook/dashboard/src || trueRepository: dallay/cortex
Length of output: 6447
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the project's AccordionTrigger wrapper
WRAP="apps/rook/dashboard/src/components/ui/accordion/AccordionTrigger.vue"
echo "=== AccordionTrigger wrapper: $WRAP ==="
wc -l "$WRAP"
cat -n "$WRAP" | sed -n '1,200p'
# Inspect any CSS/rotation in the wrapper dir
echo "=== Search accordion wrapper dir for rotation/open-state styling ==="
rg -n "data-state|open|rotate\\(|AccordionChevron|transition" apps/rook/dashboard/src/components/ui/accordion || true
# Sanity check: ApiKeyForm imports AccordionTrigger from local wrapper
FILE="apps/rook/dashboard/src/components/ApiKeyForm.vue"
echo "=== AccordionTrigger import lines in ApiKeyForm.vue ==="
rg -n "AccordionTrigger" "$FILE" | head -n 50Repository: dallay/cortex
Length of output: 2724
Fix accordion chevron duplication/non-rotation in ApiKeyForm.vue
AccordionTrigger is wrapped by apps/rook/dashboard/src/components/ui/accordion/AccordionTrigger.vue, which always renders its own default (rotating) ChevronDown. Your manual ChevronDown at line 329 is nested inside an inner <div>, so it won’t match the wrapper’s &[data-state=open]>svg rule and will stay static, likely resulting in two chevrons (one rotating, one not). Remove the manual ChevronDown and rely on the wrapper, or override via the trigger’s #icon slot.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/rook/dashboard/src/components/ApiKeyForm.vue` around lines 308 - 331,
The AccordionTrigger wrapper (component AccordionTrigger) already renders a
rotating ChevronDown, but ApiKeyForm.vue currently also renders a manual
<ChevronDown> inside the trigger div causing duplication and non-rotation;
remove the manual ChevronDown element from the AccordionTrigger block in
ApiKeyForm.vue (or alternatively move it into the trigger’s `#icon` slot if you
need a custom icon) so only the wrapper-controlled chevron is rendered and
rotation styles apply correctly.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
The Vue component uses the Accordion UI primitives and ChevronDown icon. Vitest was failing because these weren't mocked in the spec file. Co-authored-by: copilot
The E2E tests expect the dashboard on localhost:4747. Without this setting, Vite defaults to 5173 and global-setup.ts fails with ERR_CONNECTION_REFUSED.
Avoid SyntaxError when API returns HTML instead of JSON (e.g. 404
pages, redirects). Also handle both { providers: [...] } wrapper
and direct array response formats.
Fixes 9 failing E2E tests in PR #145
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
apps/rook/dashboard/e2e/api-keys.spec.ts (3)
10-14:⚠️ Potential issue | 🟠 Major | ⚡ Quick winNormalize
DASHBOARD_URL_BASEbefore appending/.
DASHBOARD_URL_BASE + '/'still produces...//whenprocess.env.DASHBOARD_URLalready includes a trailing slash, which reintroduces broken navigations like.../dashboard//api-keysfor configured environments.Suggested fix
-const DASHBOARD_URL = DASHBOARD_URL_BASE + '/' +const DASHBOARD_URL = `${DASHBOARD_URL_BASE.replace(/\/+$/, '')}/`🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/rook/dashboard/e2e/api-keys.spec.ts` around lines 10 - 14, DASHBOARD_URL can end up with a double-slash when process.env.DASHBOARD_URL already has a trailing slash; to fix, normalize DASHBOARD_URL_BASE by stripping any trailing slashes before appending '/' so concat always yields a single trailing slash (e.g., replace trailing slashes from DASHBOARD_URL_BASE using a regex like .replace(/\/+$/, '') or String.prototype.replace/trimEnd), then build DASHBOARD_URL from that normalized DASHBOARD_URL_BASE; update the variables DASHBOARD_URL_BASE and DASHBOARD_URL accordingly.
780-829:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFail loudly when the provider seed is missing.
Wrapping the whole scenario in
if (providers.length > 0)turns this into a silent pass whenever/api/providersis empty or broken, so the restriction-clearing path never runs. Assert the precondition instead of skipping the body implicitly.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/rook/dashboard/e2e/api-keys.spec.ts` around lines 780 - 829, The test currently skips silently when no providers are returned by getProvidersViaApi because of the `if (providers.length > 0)` guard; replace that conditional with an explicit precondition assertion (e.g., assert/expect that `providers.length` is greater than 0 with a clear failure message) immediately after calling `getProvidersViaApi(page)` so the test fails loudly when the provider seed is missing and the subsequent code that references `providers[0]` always runs when the precondition holds.
705-709:⚠️ Potential issue | 🟠 Major | ⚡ Quick winVerify that the extra provider was actually persisted.
This test currently passes as soon as the dialog closes. If the checkbox interaction is a no-op or the save drops the new provider, the regression still goes green. Fetch the key after save and assert
allowedProviderscontains the newly added provider ID.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/rook/dashboard/e2e/api-keys.spec.ts` around lines 705 - 709, After clicking the save button (the await page.getByRole('button', { name: /save changes/i }).click()) and waiting for the dialog to close, fetch the saved API key and assert its allowedProviders includes the newly added provider ID: use the test's HTTP client (e.g., page.request or the existing helper used elsewhere in the file) to GET the key by its id and assert response.json().allowedProviders contains the provider id you checked in the UI (the same id used when toggling the provider checkbox), rather than relying solely on the dialog closing.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/rook/dashboard/src/components/ApiKeyForm.spec.ts`:
- Around line 160-183: Add a new unit test in the ApiKeyForm.spec.ts suite that
interacts with the provider-kind group checkbox (selector pattern
"provider-kind-checkbox-<provider>") to cover group-selection logic in
ApiKeyForm.vue: mount the component with a sample providers prop, click the
provider-kind checkbox to toggle all child provider checkboxes, then assert the
emitted allowedProviders payload matches the expected set after the toggle and
verify the group's checkbox DOM state transitions (checked, unchecked,
indeterminate) and any displayed selected-count updates; use existing
per-provider selectors (e.g., "provider-row-*" or "provider-checkbox-*") to
confirm child checkboxes change accordingly and that subsequent toggles produce
correct emissions and states.
---
Outside diff comments:
In `@apps/rook/dashboard/e2e/api-keys.spec.ts`:
- Around line 10-14: DASHBOARD_URL can end up with a double-slash when
process.env.DASHBOARD_URL already has a trailing slash; to fix, normalize
DASHBOARD_URL_BASE by stripping any trailing slashes before appending '/' so
concat always yields a single trailing slash (e.g., replace trailing slashes
from DASHBOARD_URL_BASE using a regex like .replace(/\/+$/, '') or
String.prototype.replace/trimEnd), then build DASHBOARD_URL from that normalized
DASHBOARD_URL_BASE; update the variables DASHBOARD_URL_BASE and DASHBOARD_URL
accordingly.
- Around line 780-829: The test currently skips silently when no providers are
returned by getProvidersViaApi because of the `if (providers.length > 0)` guard;
replace that conditional with an explicit precondition assertion (e.g.,
assert/expect that `providers.length` is greater than 0 with a clear failure
message) immediately after calling `getProvidersViaApi(page)` so the test fails
loudly when the provider seed is missing and the subsequent code that references
`providers[0]` always runs when the precondition holds.
- Around line 705-709: After clicking the save button (the await
page.getByRole('button', { name: /save changes/i }).click()) and waiting for the
dialog to close, fetch the saved API key and assert its allowedProviders
includes the newly added provider ID: use the test's HTTP client (e.g.,
page.request or the existing helper used elsewhere in the file) to GET the key
by its id and assert response.json().allowedProviders contains the provider id
you checked in the UI (the same id used when toggling the provider checkbox),
rather than relying solely on the dialog closing.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: a4b831a2-ae67-4329-9fee-b3a1b6c4e590
📒 Files selected for processing (3)
apps/rook/dashboard/e2e/api-keys.spec.tsapps/rook/dashboard/src/components/ApiKeyForm.spec.tsapps/rook/dashboard/vite.config.ts
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/rook/dashboard/e2e/api-keys.spec.ts (1)
681-724:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winCapture the created key before using
key.id.Line 681 awaits
createApiKeyWithProvidersViaApi(...)without storing its return value, but Lines 718-723 readkey.id. This test will throw before it reaches the new persistence assertion.Suggested fix
- await createApiKeyWithProvidersViaApi(page, keyLabel, ['chat:read'], 'free', [firstProvider.id]) + const key = await createApiKeyWithProvidersViaApi( + page, + keyLabel, + ['chat:read'], + 'free', + [firstProvider.id], + )🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/rook/dashboard/e2e/api-keys.spec.ts` around lines 681 - 724, The test calls createApiKeyWithProvidersViaApi(...) but never captures its return value and later references key.id; update the call to assign the result to a variable (e.g., const key = await createApiKeyWithProvidersViaApi(page, keyLabel, ['chat:read'], 'free', [firstProvider.id])) so subsequent code that uses key.id (the request to GET /api/api-keys/${key.id} and the savedKey assertion) has the created key object available.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/rook/dashboard/e2e/api-keys.spec.ts`:
- Around line 712-723: The test currently assumes the second provider from the
API response (secondProviderId = providers[1].id) matches the second checkbox in
the UI, which is flaky; instead, drive selection from the UI and assert using
that provider's id: locate the provider row/label element you clicked (use the
same selector used to toggle the checkbox), extract the provider identifier from
a DOM attribute or nearby element (e.g., data-provider-id, data-id, or text
label you can map to an id), then use that extracted id in the API GET/assertion
(replace secondProviderId with the id you read from the UI). Ensure the
CSRF/auth cookie retrieval and the request to
`${API_BASE_URL}/api/api-keys/${key.id}` remain unchanged (getCsrfToken,
page.context().cookies, keyResponse, savedKey).
---
Outside diff comments:
In `@apps/rook/dashboard/e2e/api-keys.spec.ts`:
- Around line 681-724: The test calls createApiKeyWithProvidersViaApi(...) but
never captures its return value and later references key.id; update the call to
assign the result to a variable (e.g., const key = await
createApiKeyWithProvidersViaApi(page, keyLabel, ['chat:read'], 'free',
[firstProvider.id])) so subsequent code that uses key.id (the request to GET
/api/api-keys/${key.id} and the savedKey assertion) has the created key object
available.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: d2d85141-0276-472f-9b2c-7b4f4425c0e2
📒 Files selected for processing (2)
apps/rook/dashboard/e2e/api-keys.spec.tsapps/rook/dashboard/src/components/ApiKeyForm.spec.ts
…-new-provider test
- Assign result of createApiKeyWithProvidersViaApi to const key (fixes undefined key.id)
- Use provider-checkbox-${secondProvider.id} data-testid instead of nth(1) index
to drive selection, then use same provider id for the assertion
… empty Replace hard expect() failures with test.skip() guards so the 3 provider-restriction tests skip cleanly in Docker environments that don't have providers seeded, instead of hard-failing. Also fix indentation in 'clears provider restrictions via UI' test where 6-space indent incorrectly nested the test body inside a stale 'if' block from a prior edit.
|
1 participant
Summary
Fixes E2E test infrastructure issues in
api-keys.spec.tsso all 47 tests pass (7 webkit skipped due to known CSRF Docker image issue, 0 failures).just ci-local: ALL PASSED ✓ (369s total)Changes
1.
getByRole('checkbox')for reka-ui Checkbox (clears provider restrictions via UItest)The previous selector
[data-testid^="provider-checkbox-"]targeted the wrapper, andsetChecked()on it didn't trigger the@update:model-valueevent that updates the Vue form state.reka-ui Checkbox uses a visually-hidden
<input>withrole="checkbox"on the visible button. Clicking the role=checkbox element correctly dispatches the events.2. Double-slash URL bug:
/dashboard//api-keys${DASHBOARD_URL}/api-keysproduced/dashboard//api-keysbecauseDASHBOARD_URLalready ends with/. Switched to${DASHBOARD_URL}api-keys(no leading slash) for navigation.3. Cookie scope fix in
global-setup.tsurl: DASHBOARD_URLincontext.addCookies()inferredpath: /dashboard, which blocks cookies from being sent to Vite-proxied/api/*routes (different path).4.
127.0.0.1for API (macOS Docker userland proxy)macOS Docker userland proxy only forwards IPv4;
localhostresolves to::1first, causingECONNRESET. API calls now default tohttp://127.0.0.1:8081(the host-mapped Docker port). DASHBOARD_URL keepslocalhostsince Vite dev server runs onlocalhost:4747.5.
API_BASE_URLconstant restoredThe constant was accidentally dropped in a prior edit, causing
ReferenceError: API_BASE_URL is not definedon test startup.Test Results
How to Run Locally