Splunk rex command field collision and precedence

Field Overwrite Behavior

Yes, the rex command overwrites the existing field value for the remainder of the search pipeline. If a named capture group in a rex statement matches a field name that already exists—whether it was created via index-time extraction, props.conf, or a previous command—the rex command replaces the original value with the new match.

The original field value is not preserved in a hidden state; it is permanently replaced in the result set for that specific search execution. Once the overwrite occurs, subsequent commands in the pipeline will only see the value produced by the rex command.

Precedence and Pipeline Logic

Splunk follows a "last-writer-wins" logic within the search pipeline. The precedence is determined by the order of operations:

• Configuration vs. Inline: A rex command in the search string takes precedence over fields extracted via props.conf or fields.conf.
• Sequential rex Commands: If multiple rex commands target the same field name, the most recent command in the pipeline determines the final value.
• Internal Capture Groups: If a single rex command contains multiple capture groups with the same name, the last successful match in the event string typically determines the field value.

Verification Steps

To verify this behavior in your environment (assuming Splunk Enterprise or Cloud), execute the following sequence:

1. Identify an event with an existing field (e.g., user).
2. Run a search to confirm the original value: index=your_index | table user.
3. Apply a rex command to overwrite that field: index=your_index | rex field=_raw "(?<user>OVERWRITTEN)" | table user.
4. Confirm that the user field now displays "OVERWRITTEN" and the original value is no longer accessible.

Operational Caution

Avoid using rex to overwrite system-protected fields such as _time, host, or source. Overwriting these can break time-based visualizations, bucketing, and index-level filtering.

Diagnostic Detail Required: Are you attempting to overwrite a field that is being used as a primary key for a stats or transaction command later in your pipeline? This would change the recommendation from a simple rex to using eval with a renamed temporary field to preserve the original identity.