Description:

Background

Several AFs (e.g. AF-17321,AF-12502, AF-15656, AF-18247) have crashed with invalid memory access traced to pointer arithmetic on corrupted BSON field offsets. The crashes occur while iterating over or extracting elements from a BSON document that contains invalid internal structure (e.g. corrupted element length or type byte).

Observed behavior

• Crash stack involves BSON element traversal triggered by a multi-part update with multipath field names.
• The invalid memory access originates from arithmetic using a corrupted offset value within the BSON document.
• Cluster validation finds no corruption in data at rest, indicating the corrupted document is probably not persisted — it is constructed transiently as part of update processing and never reaches the storage layer.

Goal

Add structured diagnostic logging at the site(s) which triggered the problematic BSON element extraction throws (in the update execution stack). We should capture details such as:

• The raw BSON bytes of the offending document (hex-encoded, bounded by a reasonable size limit)
• The field path(s) being applied (multipath update field names)
• The update operation type (e.g. $set, $unset, etc.)
• The current element offset and reported element size at the point of failure

This will allow us to reproduce the update operation offline and identify exactly which step in the update pipeline is producing the corrupted intermediate document.

The log should gated so it does not fire on healthy documents (i.e. only on caught exceptions or explicit validity checks that fail).

No performance impact on the hot path under normal (non-corrupt) operation.