None of the supplied hashes were valid



This morning I noticed there was an error which called my onStopped listener and the method disconnected the client.
[INFO] Stopped:
[INFO] None of the supplied hashes were valid
[INFO] Disconnected…

I’m using a StreamConsumer object to connect to the streaming Api of type HTTP_MULTI.

In my Java class I create hashes and update my object to subscribe and unsubscribe accordingly. All hashes are created using Datasift’s api calls.

However, all of the supplied hashes were valid.
My logs reported all hashes that were submitted to Datasift before and after the error and are listed below. I’ve checked them and all seem to be valid.

“b34de3af46614142a46e101ce011ed07”; //08:39:41
"c6c36ac23fdb2fc39044c5965a72c156"; //08:44:37
"d5d7ed558f000043fb5915469133095d"; //08:47:46
"2796238d5fdfa617bcdd7ca115922be4"; //08:47:49
"63ac3c54da0493a9f016e156d2916279"; //08:48:52
Error happened here. //08:48:53
"c17fe6268b8448616cdcca164345b73a"; //09:26:40

What do you think has happened?

Having played around with implementing IMultiStreamConsumerEvents, I’ve noticed the following behaviour:
The consumer receives a failure with “None of the supplied hashes were valid” message in two following cases:

  1. If all of the hashes in the arraylist are not valid
  2. If you supply NULL as the only element in the list.

I really don’t know what happened because:

  1. I’ve checked the hashes submitted and no hash was invalid. Even if you submit an empty arraylist, there is no such error/message.
  2. Even if DS gave me a null response I would have logged the exception message.

Unfortunately we lost some data due to that. Any ideas what is the problem and how to fix it in case its on our side?


Michael Vogiatzis


It looks like this was due to a transient issue from our side, which caused the Streaming API to incorrectly return a 400 error, rather than something in the 5xx range. I have rasied an issue against the Java client library to look into resolving this behaviour. If you submit a ticket at, we can look into recovering this lost data for you. 


Thanks for the ticket, no need to recover any lost data.

Michael Vogiatzis