Skip to content

Commit e08d069

Browse files
icecrasher321claude
andcommitted
test(provenance): give the label-protection test a live matcher again
Cursor caught the third instance of the same shape: the fixture `TOK` is three characters, so the floor drops it and the matcher is empty. The assertion was `'Bearer {{TOKEN}}'` in and out, which an empty matcher satisfies exactly as well as working label protection — the test could no longer tell them apart. Use a fixture over the floor whose label still contains its own plaintext, and project the bare plaintext first. That control fails if the matcher is inert, so the atomic-label assertion beside it can only pass for the right reason. Auditing every test on this branch for the shape — all fixtures below the floor — returned twenty-four, but the rest are sound: most assert that nothing is substituted, which the floor makes more certain rather than less, and the remainder run through the resolver's causal path, which never consults a matcher. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 parent db10ffa commit e08d069

1 file changed

Lines changed: 13 additions & 4 deletions

File tree

apps/sim/executor/utils/resolved-secret-content-projection.test.ts

Lines changed: 13 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -292,13 +292,22 @@ describe('projectResolvedSecretModelContent', () => {
292292

293293
it('atomically projects the selected provenance label when its name contains the value', () => {
294294
const registry = new ResolvedSecretTraceRegistry([
295-
{ name: 'TOKEN', plaintext: 'TOK', encryptedValue: 'ciphertext' },
295+
{ name: 'TOKENVALUE_NAME', plaintext: 'TOKENVALUE', encryptedValue: 'ciphertext' },
296296
])
297-
registry.recordResolved('TOKEN', 'TOK')
297+
expect(registry.recordResolved('TOKENVALUE_NAME', 'TOKENVALUE')).toBe(true)
298298

299-
expect(projectResolvedSecretModelContent('Bearer {{TOKEN}}', registry)).toEqual({
299+
/**
300+
* The label `{{TOKENVALUE_NAME}}` contains the plaintext that produced it, so it is only left
301+
* alone because the label is treated atomically. Projecting the bare plaintext first proves the
302+
* matcher is live — without it an empty matcher would satisfy the second assertion too.
303+
*/
304+
expect(projectResolvedSecretModelContent('Bearer TOKENVALUE', registry)).toEqual({
305+
safe: true,
306+
value: 'Bearer {{TOKENVALUE_NAME}}',
307+
})
308+
expect(projectResolvedSecretModelContent('Bearer {{TOKENVALUE_NAME}}', registry)).toEqual({
300309
safe: true,
301-
value: 'Bearer {{TOKEN}}',
310+
value: 'Bearer {{TOKENVALUE_NAME}}',
302311
})
303312
})
304313

0 commit comments

Comments
 (0)