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

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

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

Comments

@zmanian
Copy link
Member

zmanian 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.

@alexanderbez
Copy link
Contributor

alexanderbez 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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants