You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We’re observing a rare and intermittent issue in Geth 1.12 where consecutive calls to two functions—setTime() (which sets time = now) followed by getTime() (which returns the stored time)—occasionally result in inconsistent values. Specifically, after setting time and subsequently retrieving it, the second getTime() call sometimes returns a value exactly one unit lower than the previous call. For example, the first retrieval might return 0xaab, while the next consecutive retrieval returns 0xaaa (exactly -1), despite blocks being mined at 5-second intervals and the calls being strictly sequential. This anomaly has occurred only a few times over several years of continuous node operation, and the root cause remains unknown.
Has anyone experienced a similar issue or can shed light on why this might be happening?
The text was updated successfully, but these errors were encountered:
Interesting, do you have some code for us to try to repro it better? On what kind of network are you running? Maybe in the case of a reorg where the miner mines a block a second earlier or with a bit of clock skew this might happen.
Sorry for replying so late to this, but it would be really interesting to understand your setup!
We’re observing a rare and intermittent issue in Geth 1.12 where consecutive calls to two functions—setTime() (which sets time = now) followed by getTime() (which returns the stored time)—occasionally result in inconsistent values. Specifically, after setting time and subsequently retrieving it, the second getTime() call sometimes returns a value exactly one unit lower than the previous call. For example, the first retrieval might return 0xaab, while the next consecutive retrieval returns 0xaaa (exactly -1), despite blocks being mined at 5-second intervals and the calls being strictly sequential. This anomaly has occurred only a few times over several years of continuous node operation, and the root cause remains unknown.
Has anyone experienced a similar issue or can shed light on why this might be happening?
The text was updated successfully, but these errors were encountered: