strange behavior with 2 stream filters on same stream

+2 votes
Hi guys,

i have a strange behavior with 2.0.6:

I have a stream with 2 streamfilters named e.g. A and B activated.

When an item does not match a filter you will normally get the following response:

Transaction didn't pass stream filter A: Message A

Transaction didn't pass stream filter B: Message B

now I disabled filter B and tried to add an item which conforms to filter A (but not B) but I get:
Transaction didn't pass stream filter A: Message B

with error message from filter B which I don't understand. There should not be an error as B was disapproved and also the message/filter name is wrong...
I also checked the filtercode of filter A and the active filters with listStreams(streamName,true) and only filter A was active.

asked Jul 2 by ironmanager
This has been forwarded to the team.
Can you, please, confirm that:

1. You have more than one node (probably even more than two)
2. You see this on non-miner node (or at least there are other miner nodes)
3. Issue resolved even with 2.0.6 after MultiChain is restarted
4. 'create streamfilter' transactions are confirmed in the same block (in liststreamfilters output they appear with the same first number of filterref)
1 --> it is a single node

2 --> only one node

3 --> no still the same wrong filter name :(

4 --> no I created the filters not at the same time. filterref is different. But I approved/activated both filters at the same time.

strangely I also got an error when using liststreamkeyitems:

    "result": [
            "publishers": [
            "keys": [
            "key": "myKey1",
            "offchain": false,
            "available": false,
            "error": "Stream item did not pass filter filtername: errormessage",
            "data": null,
            "confirmations": 792,
            "blocktime": 1593682508,
            "txid": "edd7f1fe71b233900553381eca65a257c2b96c68560b4705c4d2ddf44fd013d4"
    "error": null,
    "id": null

I have never got that error when reading an entry. Only when trying to write an entry not conforming to a this entry shouldn't exist as the filter should have blocked it?

Will test with 2.0.7 soon

1 Answer

0 votes
We think we understand what may have caused this. Can you please confirm whether 2.0.7 fixes it?
answered Jul 5 by MultiChain
awesome guys! 2.0.7 seems to fix the issues!!! I will let you know if I have that errors again but as of now it seems to work again! Thanks!
Great, thanks. If there is not an issue with confidentiality, would it be possible to stop the node and send us the blockchain directory, so we can verify the exact circumstances? If possible please send to multichain dot debug at gmail dot com.
unfortunately it is currently not possible :( The blockchain is about 400mb and contains sensitive data.
Although the node is now updated to 2.0.7. So you wouldn't see any errors anymore? If I stumble upon the error again in a testnode I will contact you again
OK, understood. We were just interested to see the exact ordering and timing of transactions that caused this problem, to be 100% sure we had correctly identified the underlying cause in 2.0.6 and it was not some other issue.