test_lightningd.py: lightningd currently calls getblock, not getblockhash.

[bitonic-cjp]

Without this change, the test fails for me. To be honest, I don't know how this could ever have worked, or what change made it fail.

For me, this test (without the patch) already failed in the commit that added it (737a714), so it doesn't seem to be a later regression.

[cdecker]

Just encountered the same issue. getblockhash is usually called to learn about the next height's hash and then getblock is used to retrieve that specific block. However it seems that the test framework doesn't catch the getblockhash call (especially when running with valgrind in my case), so we loop on getblock forever.

[bitonic-cjp]

The Travis bot seems to disagree: in its log, I see getblockhash (and strange enough no getblock?). What does this depend on?

[ZmnSCPxj]

I believe this to be a timing issue. On some systems the startup is long enough that the daemon has switched to getblock, while on the faster CI the daemon is still doing getblockhash.

[bitonic-cjp]

In that case, what would be a robust fix? We could get rid of both - it seems good enough to just check for estimatesmartfee. Or we could make a more permissive regex that accepts both.

[ZmnSCPxj]

I think it best to summon @rustyrussell for an opinion, as it is a test for code he added.

[rustyrussell]

Sorry, I have fix for this pending in my queue, since I also hit it locally.

I'll push in a separate PR now.