Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Halt at blocktime rather as an alternative to halt at block height #4979

zmanian opened this issue Sep 2, 2019 · 1 comment · Fixed by #5005


Copy link

commented Sep 2, 2019

@mdyring suggested that it would facilitate easier upgrades if we had functionality to halt a node at any blocktime greater than a target time.

This would enable a simpler upgrade procedure that would reliably target a specific upgrade time rather than a block height which is difficult to reliably target weeks out.


This comment has been minimized.

Copy link

commented Sep 3, 2019

This could certainly be useful! I propose we still keep halt-height but also introduce halt-time as you've outlined. As a side note, we also need to fix the corresponding logic to not exit directly, so outside defers can run:

	defer func() {
		halt := app.haltHeight > 0 && uint64(header.Height) == app.haltHeight
		halt = halt || (app.haltTime > 0 && header.Time.UnixNano() > app.haltTime.UnixNano())
		if halt {
			app.logger.Info("halting node per configuration", "height", app.haltHeight)
			_ = p.Signal(os.Interrupt)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.