Evidencefilter-obj-20

This changes whether a property is writable or configurable

filter-obj#20, at commit 2c35cf8. A closed issue from a repository Credda did not choose.

LIVE2026-09-20

RIGHT_FAILURE

executed against the upstream checkout.

Outcome: PARTIALLY_VERIFIED
Wall time: 118.9s
Checks: 5 passed of 5 applicable

RECORDED

NOT_GRADED

graded from the transcript committed with this case.

Outcome: not recorded
Checks: none run

Repository: sindresorhus/filter-obj
Issue: #20
Pinned commit: 2c35cf8092f82611cfd6ace8b8260d97f126edbf

01The signal

The report, exactly as it was filed.

Nothing paraphrased or cleaned up. The mess is the thing under test.

filter-obj#20 · as filedcommit 2c35cf8

This changes whether a property is writable or configurable

The new properties returned by this library are always writable and configurable, even when the original properties were not. While non-writable or non-configurable properties are sometimes problematic, there are sometimes legitimate reasons for it. This seems to be an unintentional side effect.

```js
const obj = Object.defineProperty({}, 'prop', { value: true, enumerable: true, writable: false, configurable: false })
const objCopy = includeKeys(obj, ['prop'])
console.log(Object.getOwnPropertyDescriptor(objCopy, 'prop'))
// { value: true, writable: true, enumerable: true, configurable: true }
```

Additionally, when a property is using `get`/`set`, they are currently removed.

```js
const obj = Object.defineProperty({}, 'prop', { get: () => Math.random(), enumerable: true })
console.log(obj.prop, obj.prop) // Different random numbers
const objCopy = includeKeys(obj, ['prop'])
console.log(objCopy.prop, objCopy.prop) // Same random numbers
```

Instead of retrieving then copying the property values, the descriptors should be used instead.

https://github.com/sindresorhus/filter-obj/blob/36e5f3a87cadeed6ef1d2da8f0362d048d3720e5/index.js#L8
https://github.com/sindresorhus/filter-obj/blob/36e5f3a87cadeed6ef1d2da8f0362d048d3720e5/index.js#L20

Note: I can submit a PR.

Repository: sindresorhus/filter-obj
Issue: #20
Commit: 2c35cf8092f82611cfd6ace8b8260d97f126edbf
Why this commit: The first parent of the fix commit de9a9371aa1108c9fb785dd11753689eb3058258, which GitHub binds to this issue via CLOSED_EVENT_PR. 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.

expected.reportedFailurecommitted with the case

Symptom: Object.getOwnPropertyDescriptor((includeKeys((Object.defineProperty({}, 'prop', { value: true, enumerable: true, writable: false, configurable: false })), ['prop'])), 'prop') produces { configurable: true, enumerable: true, value: true, writable: true }; the fix makes it produce { configurable: false, enumerable: true, value: true, writable: false }.
Expression: Object.getOwnPropertyDescriptor((includeKeys((Object.defineProperty({}, 'prop', { value: true, enumerable: true, writable: false, configurable: false })), ['prop'])), 'prop')
Reported output: { value: true, writable: true, enumerable: true, configurable: true }
Where that came from: Read mechanically from the report's fenced code, NEXT_LINE form: `console.log(Object.getOwnPropertyDescriptor(objCopy, 'prop')) // { value: true, writable: true, enumerable: true, configurable: true }`.

03What happened

The live run reproduced the reported failure.

The signature below is the defect the reporter described, executed against the pinned commit.

captured failure signatureLIVE · normalized

`Object.getOwnPropertyDescriptor(objCopy, 'prop')` still produces { value: true, writable: true, enumerable: true, configurable: true } (read { value: true, writable: true, enumerable: true, configurable: true })

bench external · checks · LIVE5 checks · 2026-09-20

The LIVE grading as emitted. A check that did not apply is never shown as a pass.

Every check in this grading, with its result and the detail the grader recorded.
Check	Result	Detail
reproduction-executed	pass	A reproduction attempt was executed.
signature-captured	pass	`Object.getOwnPropertyDescriptor(objCopy, 'prop')` still produces { value: true, writable: true, enumerable: true, configurable: true } (read { value: true, writable: true, enumerable: true, configurable: true })
right-failure	pass	Reproduced the reported failure: Object.getOwnPropertyDescriptor((includeKeys((Object.defineProperty({}, 'prop', { value: true, enumerable: true, writable: false, configurable: false })), ['prop'])), 'prop') produces { configurable: true, enumerable: true, value: true, writable: true }; the fix makes it produce { configurable: false, enumerable: true, value: true, writable: false }.
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 2c35cf8, run the report through the CLI the way the study did.

How the study invoked itone isolated home per case

git clone https://github.com/sindresorhus/filter-obj
git checkout 2c35cf8092f82611cfd6ace8b8260d97f126edbf
npm install

CREDDA_PROVIDER=heuristic \
  npx tsx apps/cli/src/main.ts fix <repo-path> @<issue-file> --no-color

Read the full study All 158 cases