fix(dashboard): hide disabled provider connections from combo builder - #6984
diegosouzapw merged 7 commits into
Conversation
The combos page's fetchData() only filtered available connections by
testStatus ("active"/"success"), so a connection the user had
explicitly disabled (isActive: false) could still show up in the
combo builder if it carried a stale testStatus from before it was
disabled.
Add filterActiveConnections() in src/shared/utils/connectionStatus.ts
and apply it ahead of the existing testStatus filter.
Co-authored-by: itolstov <attid0@gmail.com>
Inspired-by: decolua/9router#2526
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a shared utility filterActiveConnections to exclude explicitly disabled provider connections (where isActive === false) from the active providers list on the combos page, preventing stale test statuses from incorrectly keeping them active. It also adds corresponding unit tests. The review feedback correctly identifies a potential runtime TypeError in the utility's implementation: using optional chaining (connection?.isActive !== false) preserves nullish elements in the filtered array, which can crash downstream property accesses. A code suggestion was provided to explicitly filter out nullish elements.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
|
PR #6984 — fix aprovado no probe TDD (fail-without-fix provado: sem o helper, o teste quebra por módulo ausente, exatamente como a descrição previu). ATENÇÃO — colisão real com #7118 (grupo G3c, 'include never-tested connections in combo builder'): os dois editam a MESMA linha do filtro |
…r-2526-hide-disabled-connections-combos
…-file
The combos page only filtered provider connections on testStatus, so a
connection the user had explicitly disabled survived with a stale
"active"/"success" status. The isActive + testStatus gate now lives in
the shared connectionStatus util as filterUsableConnections(), which the
page calls in a single line.
This keeps src/app/(dashboard)/dashboard/combos/page.tsx BELOW its frozen
file-size cap (4653 vs 4655 congelado — the file shrinks by 2 lines vs the
release tip) without touching config/quality/file-size-baseline.json, as
the gate asks ("modularize/extraia (DRY) para encolher").
The regression test now exercises filterUsableConnections directly instead
of hand-mirroring the page's filter chain, so it guards the real code path.
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
`connection?.isActive !== false` evaluated to true for null/undefined entries, so nullish elements survived the filter. Callers read properties off the result — filterUsableConnections() reads `connection.testStatus` — which would throw "TypeError: Cannot read properties of null". Guard with an explicit truthiness check. Covered by a test that fails against the previous predicate. Reported-by: gemini-code-assist Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
Babysit summary — CI green ✅Final state: all 15 checks pass at
Tests: 3 → 5 in
Gates run locally, all green: Nothing left needing an owner decision. Ready for human review & merge. |
…diegosouzapw#6984) * fix(dashboard): hide disabled provider connections from combo builder The combos page's fetchData() only filtered available connections by testStatus ("active"/"success"), so a connection the user had explicitly disabled (isActive: false) could still show up in the combo builder if it carried a stale testStatus from before it was disabled. Add filterActiveConnections() in src/shared/utils/connectionStatus.ts and apply it ahead of the existing testStatus filter. Co-authored-by: itolstov <attid0@gmail.com> Inspired-by: decolua/9router#2526 * chore(changelog): fragment for diegosouzapw#6984 * fix(combos): keep combos page within frozen size cap Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> * fix(combos): extract filterUsableConnections to shrink the combos god-file The combos page only filtered provider connections on testStatus, so a connection the user had explicitly disabled survived with a stale "active"/"success" status. The isActive + testStatus gate now lives in the shared connectionStatus util as filterUsableConnections(), which the page calls in a single line. This keeps src/app/(dashboard)/dashboard/combos/page.tsx BELOW its frozen file-size cap (4653 vs 4655 congelado — the file shrinks by 2 lines vs the release tip) without touching config/quality/file-size-baseline.json, as the gate asks ("modularize/extraia (DRY) para encolher"). The regression test now exercises filterUsableConnections directly instead of hand-mirroring the page's filter chain, so it guards the real code path. Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com> * fix(combos): drop nullish entries in filterActiveConnections `connection?.isActive !== false` evaluated to true for null/undefined entries, so nullish elements survived the filter. Callers read properties off the result — filterUsableConnections() reads `connection.testStatus` — which would throw "TypeError: Cannot read properties of null". Guard with an explicit truthiness check. Covered by a test that fails against the previous predicate. Reported-by: gemini-code-assist Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com> --------- Co-authored-by: itolstov <attid0@gmail.com>
…diegosouzapw#6984) * fix(dashboard): hide disabled provider connections from combo builder The combos page's fetchData() only filtered available connections by testStatus ("active"/"success"), so a connection the user had explicitly disabled (isActive: false) could still show up in the combo builder if it carried a stale testStatus from before it was disabled. Add filterActiveConnections() in src/shared/utils/connectionStatus.ts and apply it ahead of the existing testStatus filter. Co-authored-by: itolstov <attid0@gmail.com> Inspired-by: decolua/9router#2526 * chore(changelog): fragment for diegosouzapw#6984 * fix(combos): keep combos page within frozen size cap Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> * fix(combos): extract filterUsableConnections to shrink the combos god-file The combos page only filtered provider connections on testStatus, so a connection the user had explicitly disabled survived with a stale "active"/"success" status. The isActive + testStatus gate now lives in the shared connectionStatus util as filterUsableConnections(), which the page calls in a single line. This keeps src/app/(dashboard)/dashboard/combos/page.tsx BELOW its frozen file-size cap (4653 vs 4655 congelado — the file shrinks by 2 lines vs the release tip) without touching config/quality/file-size-baseline.json, as the gate asks ("modularize/extraia (DRY) para encolher"). The regression test now exercises filterUsableConnections directly instead of hand-mirroring the page's filter chain, so it guards the real code path. Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com> * fix(combos): drop nullish entries in filterActiveConnections `connection?.isActive !== false` evaluated to true for null/undefined entries, so nullish elements survived the filter. Callers read properties off the result — filterUsableConnections() reads `connection.testStatus` — which would throw "TypeError: Cannot read properties of null". Guard with an explicit truthiness check. Covered by a test that fails against the previous predicate. Reported-by: gemini-code-assist Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com> --------- Co-authored-by: itolstov <attid0@gmail.com>
2 participants
Summary
fetchData()only filtered connections by lasttestStatus("active"/"success"), so a connection the user explicitly disabled (isActive: false) could still appear as selectable in the combo builder if it retained a stale healthytestStatusfrom before it was disabled.filterActiveConnections()insrc/shared/utils/connectionStatus.tsand applied it before the existingtestStatusfilter in the combos page.Attribution
Thanks to @attid for the original implementation.
Changes
src/shared/utils/connectionStatus.ts(new):filterActiveConnections()excludes connections withisActive === false.src/app/(dashboard)/dashboard/combos/page.tsx:fetchData()now filters out disabled connections before thetestStatusgate.tests/unit/connection-status-filter-active-2526.test.ts(new): regression tests, including one that mirrors the exact combined filter used in the combos page.Test plan
node --import tsx/esm --test tests/unit/connection-status-filter-active-2526.test.ts— verified fails without the fix (module missing) and passes with itnode --import tsx/esm --test tests/unit/combos-quota-protected.test.ts tests/unit/connection-status-filter-active-2526.test.ts— all greennpx eslint src/shared/utils/connectionStatus.ts "src/app/(dashboard)/dashboard/combos/page.tsx" tests/unit/connection-status-filter-active-2526.test.ts— cleannpm run typecheck:core— clean