Possible verbatim string confusion? #3032

Activity

1. mgravell commented on Sep 16, 2026

   

   mgravell

   on Sep 16, 2026

   CollaboratorAuthor

   More actions

   Found it, and the server was innocent.

   The txt= in that log is the test's own formatting, not the wire — ConfigTests.cs builds the failure message
   with sb.Append(setting.Key).Append('='). So the real observation is a parsed pair of ("txt", "# CPU"),
   which means the line the INFO parser saw was txt:# CPU: the verbatim kind prefix survived into the payload.
   That line then fails the StartsWith("# ") section test, gets split on the colon into a key/value pair, and
   with no section header ever recognised every field lands under miscellaneous. Hence "expected CPU, got
   miscellaneous" with all the data present.

   The cause was in RawResult.GetString(out verbatimPrefix):

   if (Payload.IsSingleSegment)
   {
       s = Format.GetString(Payload.First.Span);
       return Resp3Type == ResultType.VerbatimString ? GetVerbatimString(s, out verbatimPrefix) : s;
   }
   #if NET6_0_OR_GREATER
       // use system-provided sequence decoder
       return Encoding.UTF8.GetString(in _payload);      // <-- never calls GetVerbatimString
   #else
       ...
       return Resp3Type == ResultType.VerbatimString ? GetVerbatimString(s, out verbatimPrefix) : s;
   #endif

   The multi-segment path on .NET 6+ skipped the strip entirely. Single-segment replies were fine, and so was the
   down-level branch — so it fired only when the INFO reply happened to straddle a buffer boundary, which is why
   it looked flaky, machine-specific and server-shaped. It also left verbatimPrefix empty on that path.

   Believed fixed in v3: RESPite's RespReader.ReadString linearises via Buffer(...) before inspecting the
   kind prefix, so single- and multi-segment payloads take the same path and the segment-dependence is gone.
   Confirmed locally with a throwaway [Theory, Resp(...)] over a verbatim INFO frame — the attribute generates
   right-sized, oversized, every two-chunk split point (including inside txt:) and chunk-per-byte, 43 variants,
   all green; and it does fail if the strip is disabled, so it wasn't passing vacuously. Not keeping the test:
   the defect lived in RawResult, which no longer exists, so it would guard a different code path than the one
   that broke.

   Worth noting for next time: any single-segment test of verbatim handling would have passed throughout this.
   The exhaustive splitting in the Resp attribute is what makes this class of bug findable.

   Closing as fixed in v3.
2. mgravell

   closed this as completedon Sep 16, 2026