No matching events found

[Lebski]

• Version: v4.2.0
• Python: 3.5
• OS: linux
• Geth: 1.8.6-stable, private network
  (with rpcapi="db,eth,net,web3,personal,web3")

Script

import json, web3, time
from web3 import Web3, HTTPProvider

def setup_Web3():
    global web3
    web3 = Web3(HTTPProvider('http://localhost:8545'))

def make_request(contract_interface, contract_address):
    deployed_Contract = web3.eth.contract(abi=contract_interface['abi'], address=contract_address)
    last_block_num = w3.eth.getBlock('latest').number
    event_filter = deployed_Contract.events.PermissionRequestDeployed.createFilter(fromBlock=last_block_num)
    transfer_filter = deployed_Contract.eventFilter('PermissionRequestDeployed')
    while True:
        print ("Event_filter: {}".format(event_filter.get_new_entries()))
        print ("Transfer_filter: {}".format(transfer_filter.get_new_entries()))
        time.sleep(0.1)
        print("listening...")

def handle_event(event):
    print(event)

setup_Web3()
#loading resources
make_request(contract_interface,  contract_address)`

Output

Event_filter: []
Transfer_filter: [AttributeDict({'logIndex': 0, 'transactionIndex': 0, 'blockNumber': 1262, 'blockHash': HexBytes('0x82383db66f6ac078180a1687dd54365e140c45fba85b893d374efa360c234aec'), 'address': '0x0aF62bE1f6c6a9F1c569c362eAdcDA9198eb9688', 'transactionHash': HexBytes('0x82d8591df9951bb9759a55b53fc6db26c89f9bf07373758c197217d2cdd6f60c'), 'event': 'PermissionRequestDeployed', 'args': AttributeDict({'permissionId': b'o\x80Zb\xf1\x07t\xdf\xf4\x1e\xe1\x11\x86\xbcF\x8bt=\xf9\x86\xf9\xee,\xb4\xe0\xc0\x1eL\xa4\xbe[\xef'})})]

last_block_num was set to Block 1895.
The transaction was mined in Block 1897.

[pipermerriam]

Your stacktrace shows a different event name PermissionRequestdeployed.

And it looks like it may have a casing error, since deployed is lowercase. Is that supposed to be PermissionRequestDeployed?

[Lebski]

Oh damn, sorry. I chagend the code to be minimalistic for the Issue but copied the wrong console output.
It was PermissionRequestdeployed in the Smart-Contract and I copy + pasted it in the python file.
Assert the Variable-Names as correct. Checked them in the original files at least a 1000 times.
'Sorry again.

Edit: I know it should say, but i was sort of a proof of concept

[pipermerriam]

The error appears to be a failure to find the actual event ABI for named event. Can you provide the full contract ABI for the contract in question (the one with the PermissionRequestdeployed event).

[Lebski]

Added ABI.

Might be similar issue to #209 with v3.10.0...

[Lebski]

Tested on parity, same result.

I think i found the source of the error-output. I didn't provide _from as an attribute in my event.

But this won't explain why it doesn't find any of the events. Any ideas how i could test for the source of the error?

[dylanjw]

@Lebski You are right, the reason for the error is the inclusion of _from in the event filter argument for PermissionRequestdeployed. Because there is no _from argument in the PermissionRequestdeployed event abi, web3 doesn't find an event in your contract that matches that event name + argument.

The error message is a bit misleading and could be improved to say "No matching event interfaces found".

[Lebski]

@dylanjw But the reason I added this in the first place, is because I couldn't track the event without it.
Doest the filter method work for parity+ropsten or testrpc?
I've build up a minimal example with the only purpose to trigger an event an catch it but I only get an empty list.
Or could anyone provide me with an example which is working on her/his device? So I could determine, that I've got any part which is not working properly my system.
Transactions and calls are working well...

[carver]

I've build up a minimal example with the only purpose to trigger an event an catch it but I only get an empty list.

Note the block number in the transaction receipt which shows the PermissionRequestdeployed event log. Then try creating the filter with explicit fromBlock/toBlock values that are before and after that block number. Do the events show up for you then?

The default block boundaries on filters can be unintuitive.

[carver]

Can you re-verify on the latest stable version? (v4.1.0)

[Lebski]

Same issue...
I watched other issues and noticed similar problems and all using testrpc/ganache-cli as well.

[carver]

noticed similar problems and all using testrpc/ganache-cli as well.

Ah yes, there's the known bug that ganache is case-sensitive to searches. I'd recommend a different testing backend until they get that resolved.

Closing as a duplicate of #674

[Lebski]

I'm so sorry to bother you again.
I didn't work with another testing backend either.
But I got it working with the deprecated contract.eventFilter()

Since v5 got already announced I'd love to wrap my head around before the method isn't available anymore.

event_filter = deployed_Contract.events.PermissionRequestDeployed.createFilter(fromBlock="latest")
transfer_filter = deployed_Contract.eventFilter('PermissionRequestDeployed')
    while True:vent_filter.get_new_entries()))
        print ("Transfer_filter: {}".format(transfer_filter.get_new_entries()))
        time.sleep(2)

The transfer_filter is every times successful, but the event_filter is never.

[carver]

I didn't work with another testing backend either.

What web3.py version? Which provider? What type of node?

Also, looks like a copy/paste error in your code, can you take another look?

I'm so sorry to bother you again.

No need to apologize, we're happy to help! We usually need version info and a minimal, complete, and verifiable example to provide that help. :)

[Lebski]

Thank you very much. I was worried because this issue is going on since over a month now...
What bugs me it that the deprecated method works with my setup but the new one doesn't.
I might have set the parameters wrong? I'm quite unsure about the fromBlock="latest".
I've got a low hardware and mining super slow, which caused problems in the past.

• Version: v4.2.0
• Python: 3.5
• OS: linux
• Geth: 1.8.6-stable, private network
  (with rpcapi="db,eth,net,web3,personal,web3")

Script

import json, web3, time
from web3 import Web3, HTTPProvider

def setup_Web3():
    global web3
    web3 = Web3(HTTPProvider('http://localhost:8545'))

def make_request(contract_interface, contract_address):
    deployed_Contract = web3.eth.contract(abi=contract_interface['abi'], address=contract_address)
    event_filter = deployed_Contract.events.PermissionRequestDeployed.createFilter(fromBlock="latest")
    transfer_filter = deployed_Contract.eventFilter('PermissionRequestDeployed')
    while True:
        print ("Event_filter: {}".format(event_filter.get_new_entries()))
        print ("Transfer_filter: {}".format(transfer_filter.get_new_entries()))
        time.sleep(0.1)
        print("listening...")

def handle_event(event):
    print(event)

setup_Web3()
#loading resources
make_request(contract_interface,  contract_address)`

Output

Event_filter: []
Transfer_filter: [AttributeDict({'logIndex': 0, 'transactionIndex': 0, 'blockNumber': 1262, 'blockHash': HexBytes('0x82383db66f6ac078180a1687dd54365e140c45fba85b893d374efa360c234aec'), 'address': '0x0aF62bE1f6c6a9F1c569c362eAdcDA9198eb9688', 'transactionHash': HexBytes('0x82d8591df9951bb9759a55b53fc6db26c89f9bf07373758c197217d2cdd6f60c'), 'event': 'PermissionRequestDeployed', 'args': AttributeDict({'permissionId': b'o\x80Zb\xf1\x07t\xdf\xf4\x1e\xe1\x11\x86\xbcF\x8bt=\xf9\x86\xf9\xee,\xb4\xe0\xc0\x1eL\xa4\xbe[\xef'})})]

[carver]

Cool, this highlights an interesting case. @dylanjw might have more ideas, but the first difference I notice between the two is the fromBlock='latest'. Can you try setting it to something static, like:

last_block_num = web3.eth.getBlock('latest').number
deployed_Contract.events.PermissionRequestDeployed.createFilter(fromBlock=last_block_num)

[Lebski]

I tried using a static value as you suggest in the example.
Still the same result.
last_block_num was set to Block 1895.
The transaction was mined in Block 1897.

I got the receipt from geth:

{
  blockHash: "0xc74ba710c19be11f19629f390e8f03f7d5eb0e19d4db3db381f574be44d55ca2",
  blockNumber: 1897,
  from: "0x4f6b4c67eee111497ef2b85fc1d133d3ca3fd51b",
  gas: 194079,
  gasPrice: 18000000000,
  hash: "0x6f4e3961cd68c6532d44158b77755a4e8f3bebe629b05fa4f8d8d6591da2b33b",
  input: "0xded56e846f805a62f10774dff41ee11186bc468b743df986f9ee2cb4e0c01e4ca4be5bef52533235360000000000000000000000000000000000000000000000000000004a575400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000091d000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000002",
  nonce: 26,
  r: "0x3711c0f88f2541974a5cace6c2677f8b93244c16ceb61af38b1dc81feacd0817",
  s: "0x1d194c5ff8eff501c5406d70d2d2001a229a2aba7b0bcf2afd91fb580d8423ea",
  to: "0x2c7477dac8a800a530f19cc359205af6506afc6f",
  transactionIndex: 0,
  v: "0xc4b",
  value: 0
}

[carver]

Ok, I'm going to reopen this, and update the summary with this info. It seems like a Web3.py bug, if not in the code, then in the docs.

[dylanjw]

Since the same behavior is happening with a numbered block as with "latest", Im lead to believe this to be something else weird between the two api's. The two implementations do have some differences in the resulting filter parameters they generate. The new createFilter api will be more strict in matching events, whereas the eventFilter will be less strict.

@Lebski Can you paste the values of the following attributes?

event_filter.filter_params
transfer_filter.filter_params

[Lebski]

Thanks!

event_filter.filter_parms:

{'topics': [[], ['0xcaa1f0711b61f68acccf4ded56d6d4d50c40d4d8e4374a0fd108938d71e22966']], 'fromBlock': 614, 'address': ['0x3E11998369808487c3a7444454241619E4903c83', '0x3E11998369808487c3a7444454241619E4903c83'], 'toBlock': 'latest'}

transfer_filter.filter_parms:

{'topics': ['0xcaa1f0711b61f68acccf4ded56d6d4d50c40d4d8e4374a0fd108938d71e22966'], 'address': '0x3E11998369808487c3a7444454241619E4903c83'}

[dylanjw]

@Lebski That looks like the issue that people were seeing in #730, introduced in 4.0, fixed in 4.1. Just to be super sure you are using the version that includes the (possibly insufficient) fix, can you print the value of: web3.version.api?

[Lebski]

@dylanjw , it's web3.version.api: 4.0.0
It seems that I have unconsciously downgraded the version in my env.
I'll check the function soon but I hope it's fixed after upgrading.
I'm so sorry, I didn't noticed this.

[dylanjw]

No problem. Im glad we could get to the bottom of it! Re-open this issue if you hit an issue after upgrading.