Targets added by AppendContentAsFile / AppendFile were emitted raw — no scrubbing, no newline normalization — whenever the verification went through the post-conversion stream path.
InnerVerifier.GetTargets concatenated the appenders onto the incoming targets and then returned the whole list untouched when doExtensionConversion was false:
List<Target> list = [..targets, ..VerifierSettings.GetFileAppenders(settings)];
// When doExtensionConversion is false the targets have already been run through
// conversion and scrubbing (the only caller is the post-conversion stream path),
// so pass them through untouched to avoid double scrubbing.
if (!doExtensionConversion)
{
return (list, cleanup);
}
The comment was true of targets, which really had already been converted and scrubbed. It was not true of the appenders, which were appended on that same line and had been through neither.
Symptom
With a stream converter registered for an extension:
VerifierSettings.RegisterStreamConverter("png", ...);
await Verify(pngStream, "png")
.AppendContentAsFile("a\r\nb");
the appended .txt received file is written with literal \r\n, and with dates, paths, and any other scrubber targets left unscrubbed. Accepting it produces a .verified. file containing \r, so the next run fails with VerifiedLineEndingException (or, under FixNewlinesOnRead, simply never matches, since the in-memory received text still holds \r\n).
The identical AppendContentAsFile call on a verification with no converter registered is normalized and scrubbed as expected, so the behaviour depends on whether some other target happened to be converted.
Fix
Split the two groups: the already-processed targets still pass through untouched, while the appenders go through the normal conversion and scrubbing loop. GetFileAppenders is a lazy iterator, so it is also now materialized exactly once.
Fixed in 01a986d, covered by ExtensionConverterTests.TextSplitterWithFileAppender.
Targets added by
AppendContentAsFile/AppendFilewere emitted raw — no scrubbing, no newline normalization — whenever the verification went through the post-conversion stream path.InnerVerifier.GetTargetsconcatenated the appenders onto the incoming targets and then returned the whole list untouched whendoExtensionConversionwas false:The comment was true of
targets, which really had already been converted and scrubbed. It was not true of the appenders, which were appended on that same line and had been through neither.Symptom
With a stream converter registered for an extension:
the appended
.txtreceived file is written with literal\r\n, and with dates, paths, and any other scrubber targets left unscrubbed. Accepting it produces a.verified.file containing\r, so the next run fails withVerifiedLineEndingException(or, underFixNewlinesOnRead, simply never matches, since the in-memory received text still holds\r\n).The identical
AppendContentAsFilecall on a verification with no converter registered is normalized and scrubbed as expected, so the behaviour depends on whether some other target happened to be converted.Fix
Split the two groups: the already-processed targets still pass through untouched, while the appenders go through the normal conversion and scrubbing loop.
GetFileAppendersis a lazy iterator, so it is also now materialized exactly once.Fixed in 01a986d, covered by
ExtensionConverterTests.TextSplitterWithFileAppender.