Summary
The property test [*] skips array elements missing the targeted field in packages/data-masking/tests/unit/erase.test.ts fails intermittently in CI (e.g. this run with counterexample ["a", "id", [""]]).
The test builds array items with a hardcoded id: i sentinel to assert that sibling fields survive masking, while the targeted field name is drawn from a generator. When the generator happens to produce "id" as the targeted field, the sentinel and the target collapse into a single key, so the masker correctly replaces it with ***** and the assertion expect(result[parent][i].id).toBe(i) fails. This is a defect in the test's generator, not in the erase utility — the masking behavior is correct.
Auditing the rest of the property tests found the same latent defect in two more places: the parent.*.child and parent[*].child tests both use a hardcoded keep sentinel that the generated child field name can collide with. These haven't failed in CI yet (a 4-character exact match is less likely than 2), but would eventually hit a seed that triggers them.
Why is this needed?
The failure is seed-dependent, so it lands on unrelated PRs (it surfaced on #5387) and blocks CI with a red build that has nothing to do with the changes under review. Flaky tests erode trust in the suite and waste contributor and maintainer time re-running jobs.
Which area does this relate to?
Tests
Solution
Constrain the field-name generators so they can never collide with the sentinel keys, e.g.:
pathKey.filter((key) => key !== 'id'),
and the equivalent key !== 'keep' filter in the two latent cases.
Verified locally: the previously failing counterexample passes and repeated runs with fresh seeds are stable.
Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.
Summary
The property test
[*] skips array elements missing the targeted fieldinpackages/data-masking/tests/unit/erase.test.tsfails intermittently in CI (e.g. this run with counterexample["a", "id", [""]]).The test builds array items with a hardcoded
id: isentinel to assert that sibling fields survive masking, while the targeted field name is drawn from a generator. When the generator happens to produce"id"as the targeted field, the sentinel and the target collapse into a single key, so the masker correctly replaces it with*****and the assertionexpect(result[parent][i].id).toBe(i)fails. This is a defect in the test's generator, not in the erase utility — the masking behavior is correct.Auditing the rest of the property tests found the same latent defect in two more places: the
parent.*.childandparent[*].childtests both use a hardcodedkeepsentinel that the generated child field name can collide with. These haven't failed in CI yet (a 4-character exact match is less likely than 2), but would eventually hit a seed that triggers them.Why is this needed?
The failure is seed-dependent, so it lands on unrelated PRs (it surfaced on #5387) and blocks CI with a red build that has nothing to do with the changes under review. Flaky tests erode trust in the suite and waste contributor and maintainer time re-running jobs.
Which area does this relate to?
Tests
Solution
Constrain the field-name generators so they can never collide with the sentinel keys, e.g.:
and the equivalent
key !== 'keep'filter in the two latent cases.Verified locally: the previously failing counterexample passes and repeated runs with fresh seeds are stable.
Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.