"expected_binaries" error in search

Rob Speer rob at luminoso.com
Wed Apr 17 16:51:25 EDT 2013


I reproduced this at the command line. Here I'm storing two documents, with
IDs 'doc8' and 'doc9', into a search-enabled bucket named 'test-search'.

# This command works, even though 'lsh' is empty. I believe this is because
I've never put a field named 'lsh' in this bucket, 'test-search'.
curl -v -XPUT -H "Content-Type: application/json" -d '{"terms": "empty|en
string|en test|en", "lsh": "", "segments": "d do doc docs"}' '
http://riak.lumi:8098/riak/test-search/doc8?returnbody=true'

# However, if I use the empty string for a field that has ever been indexed
before, *then* I get a crash.
curl -v -XPUT -H "Content-Type: application/json" -d '{"terms": "",
"segments": "d do doc docs"}' '
http://riak.lumi:8098/riak/test-search/doc9?returnbody=true'


As requested, I typed that redbug command into the Erlang console, and at
the moment of the crash I get some output. The output baffles me, though.
The included ID is in the style of ID we use for actual documents, which
are stored in totally different buckets, and which I didn't refer to at all
in my testing.

16:42:24 <{mochiweb_acceptor,init,3}> {riak_solr_xml_xform,xform,
                                       [<<"<?xml version=\"1.0\"
?><delete><id>uuid-10f1a788ead64125bd7251ffc5308882</id></delete>">>]}

16:42:24 <{mochiweb_acceptor,init,3}> {riak_solr_xml_xform,xform,1} -> {ok,

delete,

[{<<"id">>,

<<"uuid-10f1a788ead64125bd7251ffc5308882">>}]}




On Tue, Apr 16, 2013 at 2:55 PM, Ryan Zezeski <rzezeski at basho.com> wrote:

> Rob,
>
> I don't know what the exact data is. The thing is that it doesn't seem to
>> cause an error on the client side; it just shows up in the server logs to
>> be noticed later.
>>
>
> A non-2XX response will be returned.  Verify that the response is 200.  If
> it isn't log an error in your app with the exact data passed.
>
>
>> I have a suspicion, though. Is it possible that when I set one of the
>> search fields to the empty string, some protocol along the way turns that
>> into the empty list, which then fails the type-check?
>>
>
> This is my initial suspicion as well.  If you can figure out the data
> causing the issue then run that redbug line while inserting the data.  From
> the output of that I should be able to figure out what is happening.
>
> -Z
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20130417/505b22e6/attachment.html>


More information about the riak-users mailing list