main has been red since 2026-08-25. Every SonarQube run reports 147 passed, 1 failed, and it is the same test every time:
[chromium] › sold-filter.spec.ts:81 › Filtering the storefront by availability › does not inflate the Filters count
Expected: "Filters"
Received: "Filters (1)"
#188 redefined the tally as "the number of chips" and moved the availability preset into the dimension system as a bar dimension. That dimension still emits a chip for any non-default status, deliberately: without one, ?status=reserved is an empty grid reading "No items yet — check back soon" with no Clear filters button and no way out except editing the URL by hand. The comment in standardDimensions.tsx says so.
The test asserts the pre-#188 rule — that a control outside the drawer must not count toward the button — and nothing updated it when that rule changed.
Why the code stays as it is
Counting bar chips differently from drawer chips would reintroduce exactly the per-screen special-casing #188 removed, and the divergence it fixed was the admin's tally drifting from the storefront's. The chip row sits beside the button showing precisely what is active, so a count that matches the chips is the coherent reading.
There is a real wart left behind: Filters (1) opens a drawer with nothing selected in it, because the one active filter lives in the bar. That is a known cost of the design rather than a defect in it, and it is not worth reopening #188 over.
Fix
Update the assertion and its comment to describe the rule that now holds. One line of test, no production change.
Found alongside: the suite is not isolated
Running the full suite locally failed three filter tests; each passes on its own with --workers=1. fullyParallel: true runs specs concurrently against one shared database, so they interfere depending on scheduling. CI has been lucky about ordering and only ever surfaced this one.
Filed separately — it is a different problem, and it is the more dangerous of the two because it makes any future failure hard to trust.
`main` has been red since 2026-08-25. Every SonarQube run reports `147 passed, 1 failed`, and it is the same test every time:
```
[chromium] › sold-filter.spec.ts:81 › Filtering the storefront by availability › does not inflate the Filters count
Expected: "Filters"
Received: "Filters (1)"
```
## It is the test that is stale, not the code
| | |
| --- | --- |
| Test last touched | `549a080`, 2026-08-23 (#137) |
| Tally logic last changed | `3242018`, 2026-08-25 (#188) |
| Did #188 update this test? | No — never touched since #137 |
#188 redefined the tally as "the number of chips" and moved the availability preset into the dimension system as a `bar` dimension. That dimension still emits a chip for any non-default status, deliberately: without one, `?status=reserved` is an empty grid reading "No items yet — check back soon" with no Clear filters button and no way out except editing the URL by hand. The comment in `standardDimensions.tsx` says so.
The test asserts the pre-#188 rule — that a control outside the drawer must not count toward the button — and nothing updated it when that rule changed.
## Why the code stays as it is
Counting bar chips differently from drawer chips would reintroduce exactly the per-screen special-casing #188 removed, and the divergence it fixed was the admin's tally drifting from the storefront's. The chip row sits beside the button showing precisely what is active, so a count that matches the chips is the coherent reading.
There is a real wart left behind: `Filters (1)` opens a drawer with nothing selected in it, because the one active filter lives in the bar. That is a known cost of the design rather than a defect in it, and it is not worth reopening #188 over.
## Fix
Update the assertion and its comment to describe the rule that now holds. One line of test, no production change.
## Found alongside: the suite is not isolated
Running the full suite locally failed **three** filter tests; each passes on its own with `--workers=1`. `fullyParallel: true` runs specs concurrently against one shared database, so they interfere depending on scheduling. CI has been lucky about ordering and only ever surfaced this one.
Filed separately — it is a different problem, and it is the more dangerous of the two because it makes any future failure hard to trust.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
mainhas been red since 2026-08-25. Every SonarQube run reports147 passed, 1 failed, and it is the same test every time:It is the test that is stale, not the code
549a080, 2026-08-23 (#137)3242018, 2026-08-25 (#188)#188 redefined the tally as "the number of chips" and moved the availability preset into the dimension system as a
bardimension. That dimension still emits a chip for any non-default status, deliberately: without one,?status=reservedis an empty grid reading "No items yet — check back soon" with no Clear filters button and no way out except editing the URL by hand. The comment instandardDimensions.tsxsays so.The test asserts the pre-#188 rule — that a control outside the drawer must not count toward the button — and nothing updated it when that rule changed.
Why the code stays as it is
Counting bar chips differently from drawer chips would reintroduce exactly the per-screen special-casing #188 removed, and the divergence it fixed was the admin's tally drifting from the storefront's. The chip row sits beside the button showing precisely what is active, so a count that matches the chips is the coherent reading.
There is a real wart left behind:
Filters (1)opens a drawer with nothing selected in it, because the one active filter lives in the bar. That is a known cost of the design rather than a defect in it, and it is not worth reopening #188 over.Fix
Update the assertion and its comment to describe the rule that now holds. One line of test, no production change.
Found alongside: the suite is not isolated
Running the full suite locally failed three filter tests; each passes on its own with
--workers=1.fullyParallel: trueruns specs concurrently against one shared database, so they interfere depending on scheduling. CI has been lucky about ordering and only ever surfaced this one.Filed separately — it is a different problem, and it is the more dangerous of the two because it makes any future failure hard to trust.