Instead of deleting the partial order (which had a bug in it that it
didn't remove the order creation timestamp) we for now only update its
status to failed. We'll want to implement proper housekeeping at one
point to get rid of archived orders. But for now we have the
--active_only flag that helps to easily filter out archived orders on
the command line.
In this commit, we add a new key within the order bucket that stores
just the node tier for a given order. The current code only _expects_ a
node tier to exist for Bid orders, however things have been designed
such that, we can easily add tier options for Ask orders as well.
Along the way we modify the `orderCallback` to include the node tier
information as its read from a distinct bucket. In the future, we'll
likely want to make this into a struct so the function signature doesn't
ever expand.
When a terminal error is received, it is not enough to stop the server
itself to terminate the trader daemon because the main goroutine still
blocks on the read from the shutdown channel.
Instead we have to request a proper shutdown through the signal package
to initiate a full trader daemon stop.
In this commit, we introduce a new field to only bids (for now): a min
node tier. This node tier is meant to allow buyers to express the level
of "quality" they're interested in for a given purchased channel. This
quality is determined using the current server-side rating system. The
base node tier are those considered "above the cut", this is also the
default tier: t1. The next node tier is t0, and is the buckets all other
nodes fall in. As the tiers rise, the number of nodes in each tier
shrinks, as these are meant to be the upper percentile of all nodes.
NOTE: The way this is implemented is actually a _breaking change_ from
the perspective of orders as we add a new field, which is included in
the order digest, without also bumping the version.
In this commit, we restrict the validation in SubmitOrder to only accept
durations of orders that show up in the Terms call. The way this is
implemented, we'll be able to easily add new durations in the future
without modifying the client each time too much.
In this commit, we replace the existing min/max duration system with a
single field that expresses the expected duration of a lease. Note that
we've left some of the exiting logic in place that select a duration
from a bid in an attempt to make this more of a "soft fork" which will
allow any existing orders to be cleared out as normal before we switch
over.
Once we add multiple durations (this commit assumes a single duration),
we'll need to modify the verification logic to be able to handle
multiple clearing prices for a given batch.
In this commit, in order to make accounting for account
modification/creation transactions a bit easier, we'll now always add a
label describing the transaction within the account manager. The user is
also able to set their own prefix to the label as well to allow
insertion of custom meta data.
In this commit, we make a series of RPC changes to do away with the
min/max order preference and instead replace that with a single unified
field for the duration of a lease. The Terms method has been extended to
return the current set of active leases. Things have been done in this
way to allow us to announce a new duration, accept orders, but not yet
enable market clearing for it.
The changes in this commit were intended to be non-breaking, which is
why the Bid/Ask message distinction still exists, even though with this
commit they nearly share all the same fields. In the future further
fields may be added that still make both messages asymmetric.
When normally connecting for the first time, the initial backoff is set
to 0 and no wait is executed. We make this a bit more clear by moving
the zero check into the loop and out of the `wait` method.
To make the auctioneer connection retry mechanism a bit more robust, we
try a "cheap" (resource wise) synchronous RPC call instead of the
streaming SubscribeBatchAuction call that'll only fail once we actually
try to authenticate an account.
That way we can catch errors if the auctioneer server is down and try a
proper reconnect.
To divert all error channels to the subscription handling the
authentication, we create a concurrency safe error channel switch that
sends the incoming error messages to the correct processing channel.
