The more verbose name was helpful in the past when some code was
handling more than one waitgroup, however that is no longer the case due
to refactoring so reverting to the more concise name makes sense.
Create the shutdown context earlier so process begins handling shutdown
signals earlier. Specifically, the context should be created before
creating any resources which need a graceful shutdown such as the
database. This is important because without explicit signal handling the
process will terminate immediately upon receiving a signal without
running deferred tasks.
Go 1.14 added runtime support for handling the windows CTRL_CLOSE_EVENT,
CTRL_LOGOFF_EVENT, and CTRL_SHUTDOWN_EVENT events by adding a definition
for syscall.SIGTERM to windows and converting the events to that signal.
It also added definitions for other common signals, including SIGHUP,
and treats them as NOOPs on windows.
Consequently, this modifies the logic that deals with conditionally
handling SIGTERM and SIGHUP to handle them for windows as well as all
unix-like operating systems, including newer ones that are supported by
Go since the code was originally written.
Although the additional signals could probably just be added
unconditionally without too much issue now due to the runtime adding
stubs to all operating systems the project officially supports, it is
safer to be explicit when dealing with syscall definitions since there
is no guarantee that they will exist for newly-added operating systems.
Upgrade the dcrwallet dependency to pick up the new version of
txrules.StakePoolTicketFee which considers the status of DCP0012 in its
fee calculation.
The vspd Run func is now blocking and returns when its provided context
is cancelled. This means it is invoked/canceled in the same way as the
webapi Run func.
webapi is now created in the main run func rather than within vspd,
further decoupling these components.
Any tasks deferred in the main func will not execute if os.Exit is
called. Moving application logic down into a new func which is called by
main works around this limitation.
vspd runs some tasks on startup - database consistency checks, catching
up with missed blocks, etc. If a shutdown is requested while these tasks
are running, vspd should stop immediately rather than continuing to
start the web API server and other background tasks.
The more verbose name was helpful in the past when some code was
handling more than one context, however that is no longer the case due
to refactoring so reverting to the more concise name makes sense.
Using a single select loop for background tasks removes a lot of
duplicated boilerplate code and helps to simplify shutdown logic. This
does reduce the amount of things which can run in parallel, but that
isn't of concern for vspd. The web server still runs in its own
goroutine so its responsiveness won't be affected.
Any tickets in the database which are currently revoked should be
updated to either expired or missed.
This is achieved with a heuristic based on the expiry height and
revoke height of the tickets. It is not guaranteed to be 100% correct
but should be pretty close.
The web api is not yet updated to reflect this change, missed/expired
tickets will continue to be counted as revoked.
Use dcrd and GCS filters to find voted/revoked tickets rather than using
the dcrwallet TicketInfo RPC.
Using TicketInfo was a bit flakey because wallets do not always
correctly detect votes/revokes, and as a result VSP admins may notice
that with this change vspd detects some historic voted/revoked tickets
which TicketInfo never detected.
Simnet params were added in the very first commit of vspd purely because
of copy/pasting from another project.
vspd has never actually been tested on simnet, so its possible
(probable) that it won't even operate correctly without additional dev
work. If we want simnet to be a properly supported network it can be
re-added and tested in the future.
Fix a bug where it appeared as though a notification handler was being
attached to the dcrd RPC client, but actually no notifications were
received until the client was disconnected a new one was created.
Now, rather than delaying attaching the notification handler, it is
attached immediately upon client creation and vspd does not start
handling the received notifications until it is ready.
Moving the existing integrity checks up into vspd removes the
depdendancy on rpc clients from the database client, and also creates a
natural home for future integrity checks to be added.
Storing all of the essential resources such as db, rpcs and logger in a
vspd struct enables vspd functions to be called without passing a bunch
of parameters unnecessarily. This will be increasingly useful later when
further changes are introduced.
The existing signal.go was inherited directly from dcrwallet, and was
slightly more flexible/complicated than required for vspd. This brings
the code more inline with the dcrd implementation which can be
instantiated in one line and with only one parameter.
Creating these closer to where they are needed tidies things up a bit,
and reduces the chance of them being used unnecessarily (as was being
done previously).
Only attach the dcrd notification listener after all other startup tasks
have been completed.
Attaching the listener before this can result in the notification
handler being invoked whilst startup tasks are still running, which
isn't necessarily a problem, but it is unnecessary and makes a mess of
logging.
