Why are my search results differing between two index-time fields?

[arkadyz1]

I have two index-time fields in my app - barcodeKey and trackId. trackId is derived from barcodeKey as a suffix.
The application can search by either one of them, and most searches for the barcode and the trackId derived from it return the same set of events.

However, some of the codes work only for barcodeKey and not trackId. While investigating, I ran a search for barcodeKey and built a table of barcodeKey and trackId, then clicked on trackId to "include only those results".

Here is the search string which it generated:
index=myIndex sourcetype=mySourceType barcodeKey="9611019060145900336056" | search trackId=060145900336056
The search still returned the same number of events as the initial barcodeKey search.

Since there is nothing transforming or renaming the fields in the above search string, shouldn't it behave exactly the same as:
index=myIndex sourcetype=mySourceType barcodeKey="9611019060145900336056" AND trackId=060145900336056 or even just the
index=myIndex sourcetype=mySourceType barcodeKey="9611019060145900336056" trackId=060145900336056, should it?

To my surprise, the last two searches returned no events! Same datetime range.

In fact, I went to the search string and fully removed the barcodeKey="..." condition. The
index=myIndex sourcetype=mySourceType trackId=060145900336056
search returns no events. This one:
index=myIndex sourcetype=mySourceType | search trackId=060145900336056
does bring back the expected set!

This is Splunk 6.3.1. I'm at a loss - any ideas what might be happening here?

[arkadyz1 · Accepted solution]

An update for the curious:

I had a fields.conf file which had two stanzas:

[barcodeKey]
INDEXED = true

[trackId]
INDEXED = true

Once I removed those INDEXED properties, a search (not exactly the same but extremely similar and suffering from exactly the same symptoms) started working! I then ran those exact searches and they started working as well.

My problem with all this is that my fix runs contrary to the description of the INDEXED property in fields.conf. However, INDEXED_VALUE, if set to true, would have produced this exact effect in trackId searches, so I wonder if there is a bug with the processing of those two properties flipped.