`serverStatus` Calls do not Always Succeed

[ata-nas]

Story Form

As a Block Node User
I want to reliably be able to call serverStatus
So that I can rely on the method

Technical Notes

• in recent k6 test runs, we notice that 95 % of around 10k calls to serverStatus succeed
• we need to investigate why so, is that a k6 issue or not
• if not a k6 issue, we need to resolve the issue

[AlfredoG87]

what is the response status in the failures?
does this still happens if we do less requests, lets say 1000? I am trying to understand if starts failing due to the load, which is my guess.

[ata-nas]

what is the response status in the failures? does this still happens if we do less requests, lets say 1000? I am trying to understand if starts failing due to the load, which is my guess.

@AlfredoG87 these are good questions, I am asking myself also. We have to do some digging in order to figure out. We need to do some debugging to see the response statuses and also to do rapid calls of the server status with something else than k6 in order to see if the issue is in k6 itself (maybe unlikely). If not, then this indicates we have an issue we need to fix in the block node.

[berryware]

serverStatus has been changed to only return the minimum block number and the greatest block number. A test of serverStatusDetails should be added to verify if this error has moved or is gone. It is not appearing in serverStatus anymore as far as I can tell.

[berryware]

@ata-nas , @AlfredoG87, I did some digging as this happens with both the serverStatus and serverStatusDetail calls. The following error is what is being encountered.

running (0m26.0s), 02/10 VUs, 6 complete and 0 interrupted iterations
default   [  14% ] 02/10 VUs  0m26.0s/3m00.0s
time="2026-03-03T20:39:57-05:00" level=info msg="gRPC error: Status DeadlineExceeded, Message: [object Object]" source=console

K6 does not allow us to set deadlines, only timeout which is different. It could be something in out set up of the block node server that is causing this.

[ata-nas]

@berryware yes, we are hitting k6 limits here juxtaposed to our env. This is something we explored with @jsync-swirlds. Unfortunately, we always expect some failures, even though the BN seems to have no issues. This is one of the shortcomings of the gRPC support of k6 it seems unfortunately.

P.S. a "retry" could be done, I've explored that, but still, sometimes we see the code 4, just less frequently. Ideally, we will be able to completely resolve this.