Block timestamp drift on dev chain with --reseal-min-period 0

[pgrzesik]

Before filing a new issue, please provide the following information.

I'm running:

• Which Parity version?: 1.8.5
• Which operating system?: Linux
• How installed?: Docker
• Are you fully synchronized?: yes
• Which network are you connected to?: development chain
• Did you try to restart the node?: yes

Your issue description goes here below. Try to include actual vs. expected behavior and steps to reproduce the issue.

Hello,
today we noticed very strange behavior (at least it's really suprising to me) that when we're using --reseal-min-period 0 (with other small values as well) flag while running our parity node with development chain, block.timestamp is quickly drifting to the future e.g. after running some transactions, it's 15 mins in the future compared to the time on dev machine and container running Parity.

Is that an expected behavior or it's an unexpected side-effect of forcing really small reseal-min-period ?

Regards,
Piotr

[awgneo]

I can confirm this issue as well with 1.8.6 and dev chains. My only fix has been to induce a fixed delay with transactions as this drift only occurs for me when I shoot them off to parity too quickly. Here is an IPC provider you can work with until this bug is fixed. This greatly slows down my unit test suite, however.

    const provider = new Web3.providers.IpcProvider("some-ipc-file", net);
    // FIXME: parity cannot execute transactions as fast as we send them; we need a delay in between
    provider.send = (payload, callback) => {

        let delay = 0;
        if (payload.method == 'eth_sendTransaction' || payload.method == 'eth_sendRawTransaction') {
            delay = 1000; // choose 1000 or higher for success
        }

        setTimeout(() => {
            Object.getPrototypeOf(provider).send.call(provider, payload, callback);
        }, delay);

    };

[awgneo]

I can confirm that this fixes the time drift issue. Thank you!!