# Howto figure out the cause of a field type conflict

**URL:** <https://community.graylog.org/t/howto-figure-out-the-cause-of-a-field-type-conflict/3848>\
**Category:** Graylog Central (peer support)\
**Tags:** pipeline-rules, debuggingpl\
**Created:** [January 17, 2018, 11:24pm UTC](https://community.graylog.org/t/howto-figure-out-the-cause-of-a-field-type-conflict/3848 "2018-01-17T23:24:52Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![jan](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/jan/32/11_2.png) [@jan](https://community.graylog.org/u/jan)\
**Post date:** [January 18, 2018, 6:10am UTC](https://community.graylog.org/t/howto-figure-out-the-cause-of-a-field-type-conflict/3848/2 "2018-01-18T06:10:53Z")

</div>

I can think of a processing pipeline that checks the field dst\_port not beeing a number and then rename it - or write a debug log entry in the graylog server.log that contains the message source (and then delete the message).

Something like the following (this is untested!)

```auto
rule "dst_port_not_long"
when
    has_field("dst_port") AND
    to_long($message.dst_port) == 0
then
   rename_field("dst_port", "dst_port_nn")
end

```

---

_[View the full topic](https://community.graylog.org/t/howto-figure-out-the-cause-of-a-field-type-conflict/3848)._