A simple test to ensure an error string returned by the securecookie lib
does not change when we upgrade to newer versions. Important because
vspd checks for this error using string comparison.
sendrawtransaction is expected to fail if the transaction already exists in the mempool or a mined block. dcrd returns two different errors which can indicate this situation. Handling for one of them already existed, and this commit adds handling for the other.
No need to manually construct HTML in this formatting func, it can simply deal with whitespace and then use <pre> tags to display.
Add some tests to validate behaviour.
The "search" input type is functionally the same as "text" but has a nice extra property - most browsers will render it with a "Clear" button to wipe the current input.
Also disable spellchecking on this input.
Checking this in middleware not only removes duplicated code from each of the handlers, but also makes things more efficient. Previously, dcrd/dcrwallet/database clients were initialized (and could possibly cause errors) **before** checking if the VSP is closed. Now the check happens before those other things.
Also bundled with some improvements to setaltsignaddr_test.go which I implemented along the way.
* Remove helper func getCommitmentAddress.
This function is only used in one place so removing it does not introduce any duplication. Removing the func also removes the need for errors.Is comparison, which will be very useful in upcoming changes.
* Rename apiError to ErrorCode.
* Don't use inline type for API errors.
* Export webapi errors.
* Export webapi request/responses.
* Add types module for API requests/responses/errors
Periodic database backups are no longer started automatically in database.Open(), and the backup written by database.Close() can now be disabled.
Only vspd itself requires backups, they are not useful for test code or future upcoming tools such as vote-validator.
This removes all of the global loggers from the project and replaces them with loggers which are instantiated in vspd.go and passed down as params.
To support this, the background package was removed. It only contained one file so it was a bit pointless anyway. It only existed so background tasks could have their own named logger.
- Rename all instances to "shutdownCtx" to be really explicit. This context is special in that it can be closed at any time without warning, so it should be obvious to the reader.
- Don't use shutdownCtx in RPC clients. Clients should not stop working immediately when shutdown is signalled, they need to keep working while the process is shutting down.
`CanTicketVote` doesn't really fit into the RPC client code as it is more of a business logic function. Moving it into the webapi package is more appropriate.
Running as sub-tests has the benefit of automatically logging the test name, no need to include it in failure messages manually. It even works if the test panics.
* Remove global cache variable.
Rather than maintaining cached data in a global variable, instantiate a cache struct and keep it in the `Server` struct.
* Store net params in RPC clients.
This means net params only need to be supplied once at startup, and also removes a global instance of net params in `background.go`.
This allows both tspend and treasury policies to be set by clients on a per-ticket basis. Preferences can be set when initially registering a ticket with `/payfee`, and can be later updated using `/setvotechoices`.
Any requests which alter treasury/tspend policy will be stored in the database using the existing accountability system.
**Note:** This does not include consistency checking, it will need to be added later when dcrwallet has an RPC to retrieve policies in batches.
vspd will now call dcrd RPC `getblockchaininfo` to determine if DCP-0010 is active, and take that information into consideration when calculating ticket registration fee.
This renames "Voting wallet status" to "VSP status" and it now includes the status of the local dcrd instance. This change impacts both the /admin page of the UI, and the response of the /admin/status API endpoint.
Errors generated during dcrd client creation were previously handled in middleware, and request handling was terminated immediately.
Now the error handling is delayed by adding the error details to the request context. This enables downstream handlers to decide what to do with the error.
