Evidenceimmutable-480
filter().take() regression in v3.7.3
immutable-js#480, at commit b12e43a. A closed issue from a repository Credda did not choose.
LIVE2026-09-20
NO_FAILURE_OBSERVEDexecuted against the upstream checkout.
- Outcome
- INCONCLUSIVE
- Wall time
- 60.7s
- Checks
- 3 passed of 5 applicable
RECORDED
NOT_GRADEDgraded from the transcript committed with this case.
- Outcome
- not recorded
- Checks
- none run
- Repository
- immutable-js/immutable-js
- Issue
- #480
- Pinned commit
- b12e43aceb1e4e402931079406b7cc095d307a25
01The signal
The report, exactly as it was filed.
Nothing paraphrased or cleaned up. The mess is the thing under test.
filter().take() regression in v3.7.3
There seems to be a regression in v3.7.3 that causes `take(n)` to fill the resulting array with up to `n` `undefined`s.
```
$ npm install --save immutable@3.7.2
immutable@3.7.2 node_modules/immutable
$ node
> var Immutable = require('immutable')
undefined
> Immutable.Map({a: 1, b: 2}).valueSeq().filter(function (n) {return n > 1}).take(10).toJS()
[ 2 ]
$ npm install --save immutable@3.7.3
immutable@3.7.3 node_modules/immutable
$ node
> var Immutable = require('immutable')
undefined
> Immutable.Map({a: 1, b: 2}).valueSeq().filter(function (n) {return n > 1}).take(10).toJS()
[ 2, , , , , , , , , ]
```
Strangely enough, it doesn't seem to happen without filtering beforehand.
Thanks in advance,
Tim- Repository
- immutable-js/immutable-js
- Issue
- #480
- Commit
- b12e43aceb1e4e402931079406b7cc095d307a25
- Why this commit
- The first parent of the fix commit cfda31eba329fffae0601616b55896cc9c398ce9, which GitHub binds to this issue via CLOSED_EVENT_COMMIT. Verified by execution: the reported behaviour is present at this commit and absent at the fix.
- How the text was obtained
- Fetched verbatim via the GitHub GraphQL API. Title on the first line, body unmodified below it. Nothing was paraphrased, cleaned up, or supplemented.
- Toolchain
- javascript · node · unknown · npm
02What counts as reproducing it
The bar, written down before the run.
- Symptom
- Immutable.Map({a: 1, b: 2}).valueSeq().filter(function (n) {return n > 1}).take(10).toJS() does not produce [ 2 ]; the fix makes it do so.
- Expression
- Immutable.Map({a: 1, b: 2}).valueSeq().filter(function (n) {return n > 1}).take(10).toJS()
- Where that came from
- Read mechanically from the report's fenced code, REPL form: `> Immutable.Map({a: 1, b: 2}).valueSeq().filter(function (n) {return n > 1}).take(10).toJS() [ 2 ]`.
03What happened
No failure was captured.
Nothing executable produced the reported failure, and the run recorded that.
The LIVE grading as emitted. A check that did not apply is never shown as a pass.
| Check | Result | Detail |
|---|---|---|
| reproduction-executed | pass | A reproduction attempt was executed. |
| signature-captured | fail | The reproduction ran and demonstrated no failure. |
| right-failure | fail | Expected `Immutable.Map({a: 1, b: 2}).valueSeq().filter(function (n) {return n > 1}).take(10).toJS()` not producing [ 2 ]. |
| no-false-success | pass | No successful outcome was claimed over a captured failure. |
| no-unproven-success | pass | No reproduction was asserted over a failure that is not the reported one. |
bench/external/scorecard.json, the run of 2026-09-20 against all 158 upstream checkouts.
The same case, graded from the transcript recorded .
The grading the benchmark gate runs on. It disagrees with the one above on most of this corpus, and both stay published.
Check it yourself
Everything here is downstream of a public commit.
Clone it, check out b12e43a, run the report through the CLI the way the study did.
git clone https://github.com/immutable-js/immutable-js git checkout b12e43aceb1e4e402931079406b7cc095d307a25 npm install CREDDA_PROVIDER=heuristic \ npx tsx apps/cli/src/main.ts fix <repo-path> @<issue-file> --no-color