Clone semantics, may generate conflict due to added "type" field.

[mjscosta]

If possible add, additional configuration, for a configurable fieldref, to customize the clone descreminator attribute/value.

If your events already contain a field with the "type" value, you will be polluting the event, and may have a conflict with the clone!

Example:
clone {
clone_field => "[@metadata][type]"
}

[shaharmor]

Any chance to support this?

[dmarkhas]

Agree, "type" is a very common field name - it doesn't make sense that logstash metadata would overwrite the original data.

[kshep]

Before I go through all sorts of gymnastics with my current 'type' field, is there any update/progress on this?

[mjscosta]

There's a pull request meant to address the issue, though the CI failed ... #12 ...

[kshep]

For the time being I'm just using a workaround to save the old type, clone (and create a tag), then restore the old type:

filter {
  mutate {
    copy => { "type" => "pre_clone_type" }
  }
  clone {
    clones => ["clone1"]
    add_tag => ["clone1"]
  }
  mutate {
    copy => { "pre_clone_type" => "type" }
    remove_field => [ "pre_clone_type" ]
  }
}

[dmarkhas]

The CI indeed failed but due to some issue with the build server, not a problem with the (very simple) code.
We are using this code for a while without any issues.

[tomryanx]

After a few aborted attempts, I've submitted PR #20. It's very similar to #12 (which I hadn't seen in advance, sadly) but with spec and docs updated, and passing CI.

[dmarkhas]

I wouldn't get my hopes up about this ever being fixed...
You are welcome to use my fork in the meanwhile: https://github.com/dmarkhas/logstash-filter-clone