[wrossmorrow-pi-bot]

Summary

Fixes the LoadGen reporting LoadGen: extproc duration avg=0.0ms (0 samples) when the
extproc server is configured with -Dextproc.update.duration_header=true.

Investigation findings

1. The property wiring is fine. Reproduced locally: running the extproc server with
   -Dextproc.update.duration_header=true and driving it via the LoadGen results in the final
   end-of-stream ProcessingResponse actually carrying the duration header:

   LoadGen: DEBUG final response case=RESPONSE_BODY
   LoadGen: DEBUG hasHeaderMutation=true
   LoadGen: DEBUG set header key=x-extproc-duration-ns value=2002666 ...
   LoadGen: extproc duration avg=0.0ms (0 samples)
   

   The server-side option (ProcessingOptions.updateDurationHeader, fed from
   -Dextproc.update.duration_header) and the header append in ExternalProcessor.processPhase
   work correctly; the duration value (e.g. 2002666 ns) is present and valid.

2. The LoadGen extraction was the bug. LoadGen.extractDurationNs required a non-empty
   protobuf HeaderValue.rawValue and parsed raw bytes, but the SDK sets the duration via
   HeaderValue.setValue(...) (see RequestContext.updateHeader → HeaderValue.newBuilder() .setKey(name).setValue(value).build()), leaving rawValue as an empty ByteString. The
   extraction therefore hit the raw == null || raw.size() == 0 → return null guard and dropped
   every sample, producing 0 samples / avg=0.0ms.

Fix

LoadGen.extractDurationNs now falls back to the header's string value when rawValue is
empty (and vice versa), then parses the resulting duration value.

Verification

• Before fix: LoadGen: extproc duration avg=0.0ms (0 samples) → After fix: LoadGen: extproc duration avg=1.2703613333333332ms (3 samples) (3 samples, real duration).
• ./gradlew clean build — BUILD SUCCESSFUL (incl. spotless + tests).

Closes the unresolved duration-tracking item from the earlier session notes.