yiimp/stratum report "LBRY Credits #block not reporting"

[roylee17]

15:56:30: LBRY Credits 1198462 not reporting 16:12:24: LBRY Credits 1198470 not reporting 16:13:28: LBRY Credits 1198471 not reporting 16:16:17: LBRY Credits 1198472 not reporting 16:18:45: LBRY Credits 1198473 not reporting 16:19:27: LBRY Credits 1198474 not reporting

yimmp was still able to conducting the mining cycle:

1. getblocktemplate()
2. distribute jobs to miners
3. submiteblock() back to the lbcd

But the accepted blocks () was not reported and entered into yimmp database, and requires operator's intervene.

[roylee17]

Follow the logic, the templ->height (acquired via getblocktemplate rpc is more recent than coind->height by 5+ blocks.

https://github.com/LBRYFoundation/pool/blob/next/stratum/coind_template.cpp#L550-L563

    int height = coind->height;
    coind->height = templ->height-1;

    if(height > coind->height)
    {
        stratumlog("%s went from %d to %d\n", coind->name, height, coind->height);
    //  coind->auto_ready = false;
    }

    if(height < coind->height && !coind->newblock)
    {
        if(coind->auto_ready && coind->notreportingcounter++ > 5)
            stratumlog("%s %d not reporting\n", coind->name, coind->height);
    }

yiimp learns block height / update by two ways:

1. actively calling lbcd rpc, such as getinfo, getblocktemplate, etc
2. notified by a stratum message mining.block_update In our case, the lbcblocknotify acts as a bridge, which subscribes to lbcd's blockupdate websocket message, and send mining.update_block message to stratum server.

We decided to investigate the 2) route first, and it turned out to be the root cause.

https://github.com/LBRYFoundation/pool/blob/next/stratum/client.cpp#L306-L307

    int coinid = json_params->u.array.values[1]->u.integer;
    if(!coinid) return false;

The stratum server silently rejects the mimg.block_update messages from the lbcdblocknotify bridge. As the coinid field was reported as string"1425" instead of integer 1425 .