GraphQL/JSON-RPC logs regression between 1.10.21 & 1.10.22

[SLoeuillet]

System information

Geth
Version: 1.10.22-stable
Git Commit: 2de49b0
Architecture: amd64
Go Version: go1.18.5
Operating System: linux
GOPATH=
GOROOT=go

Archive node

Expected behaviour

Doing a complex GraphQL query returns correct data from a block, like in 1.10.21

Actual behaviour

Too much data (logs unrelated to current block)

Steps to reproduce the behaviour

Going to GraphQL UI : http://xxxxx:8545/graphql/ui

Type the following query :

{
  block(number: 15401505) {
    number
    transactions {
      logs {
        account {
          address
        }
      }
    }
  }
}

More details

That block on etherscan : https://etherscan.io/block/15401505

On a 1.10.22 node, this query returns 257386 lines, which is a bit too much (could depend on when you run the request)
On a 1.10.21 node, this query returns 2209 lines, which seems more in the norm

[SLoeuillet]

createdContract : 163 on both sides
account : 51345 (1.10.22) vs 315 (1.10.21)

[SLoeuillet]

I suppose it is linked to #25459

[ryanschneider]

@s1na FYI this regression seems unique to the GraphQL interface, I'm not seeing the same issue w/ eth_getLogs, I still get 316 entries w/ 1.10.23:

> eth.getLogs({"fromBlock":"0xEB0221", "toBlock":"0xEB0221"}).length
315

If I had to guess, I'd say the issue is that the block(number: ) constraint is no longer ends up setting filter.block to the block's hash, but after a quick look at the code I don't see an obvious spot where that happens, but it's been a long time since I've looked at the GraphQL code.

[s1na]

Hey, thanks for reporting it. The problem was that after my changes graphql was returning all of the block logs for each transaction, blowing up the response. If you get a chance to try the linked PR, the issue should be resolved.

@ryanschneider thanks for checking JSON-RPC. After finding the bug I'm confident it only happens for graphql queries that query logs of a transaction. I modified code there so it also utilizes the log cache we added but forgot a check.

[SLoeuillet]

I would build and test it on monday morning. Thanks for the fix

[SLoeuillet]

@s1na fix tested on my personal node, works perfectly, thanks

[yiteng-guo]

@s1na I'm still seeing the regression on my end (build on d30e39b). I ran the following graphql

{
  block(hash: "0xfd29823bf38d3bab5877d4ffeae448755b9da47c7e4e6fac6988e0bed043abd6") {
    number
    transactions {
      hash
      logs {
        account {
          address
        }
        topics
      }
    }
  }
}

no logs returns for 0xe7ac6b6b01f5be91d3dbaf797059e5a18117b25f6960be1b83cefa538dffc330 but this tx does have log https://etherscan.io/tx/0xe7ac6b6b01f5be91d3dbaf797059e5a18117b25f6960be1b83cefa538dffc330#eventlog

[SLoeuillet]

I confirm that with that very same version d30e39b , logs is sometimes empty, sometimes not

[SLoeuillet]

geth 1.10.21 :
geth00_15520795.log

geth 1.11.0 d30e39b :
geth01_15520795.log