[Node Operator Question] eth_getBlockByNumber "params": ["finalized", true] Return block height not updating issue

[rayn316]

Are you running the most up to date node software?

• Yes

Did you check the documentation?

• Yes

Did you check for duplicate questions?

• Yes

Issue Description

I run multiple nodes, but using this request found that the nodes return different heights and some nodes lag behind.
Checking the node logs is synchronizing properly and getting the latest heights is also changing.
But get [“finalized”, true] Some nodes don't change.
Tried it and the node will recover after a reboot, but this happens again afterwards

curl -s -X POST "http://127.0.0.1:31361"      -H "Content-Type: application/json"      -d '{
        "id": 4,
        "jsonrpc": "2.0",
        "method": "eth_getBlockByNumber",
        "params": ["finalized", true]
     }'     | jq -r '.result.number' | python3 -c "import sys; print(int(sys.stdin.read().strip(), 16))"

Steps to Reproduce

Run multiple nodes and use this request at intervals to observe the situation

Which component is affected?

• op-geth
• op-node
• Other

Expected vs. Actual Behavior

Secure blocks are updated synchronously, no node will fall behind

Environment Details

Ubuntu 22.04

Protocol Information

op-geth version 1.101500.1-rc.1-7017b547-20250222
op-node version v1.11.2-rc.1-bc6d11a8-1740157113

Node Logs

No response

Troubleshooting Attempts

No response

Additional Information

No response

Feedback

No response

[hash1go]

In a P2P network, it seems normal for different nodes to have different latest blocks. Could you describe in detail what specific issue you are facing?

[blockPI-rayn]

#743 (comment)

[rayn316]

The difference is relatively large, with a few nodes sometimes differing by thousands and tens of thousands of block heights
ethereum-optimism/op-geth#518

[opfocus]

I think that when it recovers after restarting, it may be related to the processing of cache by shutting down the node.

[blockPI-rayn]

Can this cache be controlled by program parameters?

[opfocus]

When op-geth is turned off, the finalized block will be written to disk from the cache, and the safe block will be discarded. This is why shutdown op-geth cannot be forced and when you restart it, the query result will be expected.
The reason why ["finalized", true] lags a lot may be related to the index of transaction data. I think it might improve query results if I wait until the nodes are fully synchronized
I think it is unnecessary to use ["finalized", true] to query the synchronization status. You can use https://docs.optimism.io/operators/node-operators/json-rpc#optimism_syncstatus to query, or create metrics. Note that its URL points to op-node.
Regarding improving node performance, one possible way is to improve cache: https://docs.optimism.io/operators/node-operators/configuration/execution-config#cache
Another way is to set the hash: https://docs.optimism.io/operators/node-operators/configuration/execution-config#statescheme

[jsvisa]

As op-geth's finalized block was advanced by op-node, so if the finalized block was not updated for a long time, maybe you need to take a look at the op-node, as @opfocus mentioned, you can check it with the optimism_syncstatus RPC, and take a look at the op-node's log, to see if there's any error or warning.

[rayn316]

OK, I will pay attention to the situation of op-node in the future.