After rebuild or restart, "syncing": is "false" during the first 10 - 20 sec. (0.6.0a)

[simonmorgenthaler]

After a rebuild or also after starting a stopped node, it takes about 10 - 20 sec until the flag "syncing" from the "/api/loader/status/sync"-Endpoint is set to "true". During those first 20 seconds, "syncing" is set to false and the "height" is the one when the node stopped or the one from the snapshot. This is a problem because during these 20 seconds, there is no way to recognize that the node is not yet finished with starting or rebuilding. There is no way to distinguish it from a regular running (but stuck) node.
In my case my managing script rebuilds it again, because it thinks the node is stuck.

My suggestion: Set the "syncing" flag to "true" directly after starting the node. Set it back to "false" only after syncing really finished.

2nd possibility: Add an additional "starting" or "rebuilding" flag.

[4miners]

Sync should start faster, it's holded because of loadTransactions and loadSignatures happen before first sync timer (https://github.com/LiskHQ/lisk/blob/development/modules/loader.js#L736) and those functions are costly and do some peers processing - that is not nesecarry (both waiting for them and peers processing inside). We can call __private.syncTimer(); at the beginning of Loader.prototype.onPeersReady (before setImmediate) - that will make sync start after about 5 seconds from node start. Should be implemented.

Set syncing flag to true at node start is wrong because it doesn't reflect the actual status (will be a lie), rebuilding flag is also misleading. I'm not sure if we need another API property just to indicate that node is between start and first sync, however that can be useful - for example when node is unable to sync because there are no peers or other reasons.

There is also 3rd possibility - make your script wait X second after rebuild and then check node status. ;)

[simonmorgenthaler]

Sure, the 3rd possibility is doable. But I would classify it as "ugly/temporary workaround" ;) In my opinion the node should be marked somehow as "not-ready" until it is in a ready and stable state and started up completely. And that's independent from my scripts.