Skip to content

Commit

Permalink
v0.7.0: GH-497 (#211)
Browse files Browse the repository at this point in the history
* GH-497: first stamp; roughly moved the core shared dao utils

* GH-497: small refactoring; thinking about nicer facade

* GH-497: probably finely usable now; next I will have to analyze the places where to use the shared method, possibly also to start adjusting the number data types which will be a chaos

* GH-497: added some marks of where dao methods will be replaced and etc; also found quite a lot of dead code

* GH-497: savepoint; starting to experimentally implement the new boundholder

* GH-497: changing by small steps; added the special primitive type (but may not be used); now before adjusting PayableAccount

* GH-497: a small convinient method added; now stuck thinking of a way out of this

* GH-497: pretty dug up - big changes in progress; now finished some types replacement and want to try to integrate the shared methods for dealing with the DB

* GH-497: shared methods roughly integrated; now I will probs need to change threshold time params to take u64

* GH-497: compiling but many failing tests; I screwed a few things I guess :)

* GH-497: new direction of the architecture; key params and obvious sign attribute

* GH-497: interim commit

* GH-497: a few more tests and features hooked up

* GH-497: interim commit

* GH-497: finally in a working state where I can start to think of changing data types in table declarations.

* GH-497: interim commit

* GH-497: DB migration deployed + reorganization in some db utils for testing

* GH-497: advanced migration with realistic converting i64 to blobs almost implemented

* GH-497: migration practically complete now

* GH-497: db-migration satisfactory

* GH-497: a few more tests made pass

* GH-497: a few insignificant tests fulfilled; elaborating the concept of paymnet thresholds - and correction of the given code as it probably had not worked as intended

* GH-497: paid delinquencies tests fixed

* GH-497: backup after a long day; stabilized exact computations upon the sloped part of the payment thresholds, corner limits at the same place, etc.

* GH-497: new delinquency model seems working at the fundamental level

* GH-497: metadata collection optimized

* GH-497: fixed totals for payable and receivable and some small defects elsewhere

* GH-497: fixing tests for blockchain_interface and little cleaning

* GH-497: completed tests for upsert in blob utils

* GH-497: a lot of minor improvements, refactoring

* GH-497: clean-up before I make step toward designing views into payable and receivable tables

* GH-497: first portion of work for masq financials command, advanced

* GH-497: financials command constructor tested

* GH-497: top payable rendering works

* GH-497: works on rendring records continue

* GH-497: setting with all information to be printed works fine

* GH-497: financial command finished at masq

* GH-497: moved dao_utils over under accountent; financials backend fundamental structure is finished

* GH-497: backend: payable top and range query work

* GH-497: receivable work too now, though certain niches are yet to be worked out

* GH-497: top records and custom query mostly finished in the backend, some minor todos are still left out there"

* GH-497: knocked out two more todos in the backend and also repaired masq console output from rowid to hash

* GH-497: maybe last three todos, they were db errors in row queries; also little renaming and testing top records not using usize anymore but u16

* GH-497: taking care of forced changes in integration tests

* GH-497: documentation added; changed imperfections in rather marginal names and structures

* GH-497: late fixes; mainly Clippy

* GH-497: multinode tests repaired

* GH-574: fix clippy warnings

* GH-574: add more rpc urls for polygon mainnet

* GH-497: lint for multinode tests

* GH-497: defaults in rate pack adjusted; making help messages better; slight refactoring

* GH-497: fixing new delinquencies for a corner case with a fully empty db

* GH-497: verify bill payment a little fix in numeric orders

* GH-497: some window dressing

* GH-497: adding safe migration for rate_pack

* GH-497: verify_bill_payments enriched by the 'financials' call

* GH-497: fixing display tools to show just Gwei-pregnant accounts; payable fixed

* GH-497: receivable gwei-wei custom query fixed; engine for this type of query enhanced; accountant mod tests modified accordingly

* GH-497: backend fixed(Accountant/mod, dao_utils)

* GH-497: financials command fixed to work in gwei - if demanded

* GH-497: close to beating the monster; tests failing, errors left over but illustrative so they will lead me

* GH-497: better treatment of decimal numbers

* GH-497: refactoring - new macro added

* GH-497: refactoring...better arrangement and readability

* GH-497: urgent todos are gone

* GH-497: shorthand args implemented

* GH-497: savepoint before implementing regex

* GH-497: temp and masq num params validation rock on, a few todos are left

* GH-497: quite complicated checks and neatening of the users inputs for costum queries

* GH-497: all existing tests in FinancialsCommand repaired

* GH-497: financials command finished

* GH-497: last sweeping in node and masq with allowence of Clippy

* GH-497: fixing bad assumption with an overflow catch; this is moment before documentation check and then auto review

* GH-497: I revised MASQ-UI-v2 docs and help output for the financials command, also enhanced one confusing log in accountant/mod.rs

* GH-497: state after auto review

* GH-497: fix within all.sh

* GH-497: I set up new possible configuration of arguments for the command; also begun implementing new format for displaying the output -- at least top records works in this regard.

* GH-497: new formatting for financials command completed

* GH-497: tuning the commands features; all tests except one passing

* GH-497: help message and planning to eliminate complicated fn with using regex instead

* GH-497-review-two: financialscommand tests are passing after refactoring a lot of code

* GH-497-review-two: details, but savepoint before trying to collect strings first and compute widths out of them

* GH-497: fair simplification; some duplications and repeated computation

* GH-497: deleting unnecessary code and tests in the financials command

* 497-review-two: ordering by balance and age is defined in the backend too...

* GH-497-review-two: custom_query and all its possible suboptions thoroughly tested; code refactored

* GH-497-review-two: custom_query and all its possible suboptions thoroughly tested

* GH-497-review-two: starting minor refactoring to address individual, less important points from the first review, but just few are behind me

* GH-497-review-two: code refactoring in blob utils

* GH-497-review-two: a bit more refactoring + test on no rows returned

* GH-497-TwoInt: I've got a first set of methods or dealing with two integers

* GH-497-TwoInt: db migration things finished

* GH-497-TwoInt: basic structure stands

* GH-497-TwoInt: continuing designing the SQLParamsBuilder and the product

* GH-497: TwoInt: insert part of upsert mostly implemented

* GH-497-TwoInt: first successful pass on the variant of update with overflow

* GH-497-TwoInt: deleting some commented out code left over from the previous version

* GH-497-TwoInt: parametrizing tests and trying to cover or possibilities...so far mainly for plain updates

* GH-497-TwoInt: big int processor completed and cleaned up

* GH-497-TwoInt: started making tests of payable_dao running; added 'strict' kw assertions

* GH-497-TwoInt: first success on top records with devided big int, yeahoo!

* GH-497-TwoInt: payable tests checked and passing (except one, which to be removed maybe); refactoring of compute_financials()

* GH-497-TwoInt: small refactoring in dao_utils.rs

* GH-497-TwoInt: paid delinquencies repaired + some bringing tests back to life

* GH-497-TwoInt: interim commit

* GH-497-TwoInt: repaired more_money_received and some related stuff

* GH-497-TwoInt: our own sqlite scalar functions added to decompose big intigers at speed

* GH-497-TwoInt: added the complicated test for new sqlite fns hook up; cleaning some stuff from the i128 version in receivable dao

* GH-497-TwoInt: reworking mig config into something with more general purpose - InitConfig; interim commit

* GH-497-TwoInt: transformation from migrator config tu superior init_config is done; most of the process of hooking up sqlite functions as well

* GH-497-TwoInt: all prepared for the start of fixing the new_delinquncies() functionality

* GH-497-TwoInt: all about conn_special_setup thoroughly tested since now

* GH-497-TwoInt: receivables finally also fixed, yahooo

* GH-497-TwoInt: finishing at various places; awaiting work at big_int_db_processor...prepared

* GH-497-TwoInt: all checks done in big_int_db_procesor

* GH-497-TwoInt: tore out the mockable code being unnecessary

* GH-497-TwoInt: Clippy + multinode tests clean-up...still a failing test there though

* GH-497-TwoInt: added more entry checks for financials

* GH-497-TwoInt: more refactoring in the financials command

* GH-497-TwoInt: a bit more of refactoring for the financials command

* GH-497-TwoInt: FinancilsCommand response reworked to return a common set of records for both modes, now on the masq side

* GH-497-TwoInt: the backend side also taken care of

* GH-497-TwoInt: continuing refactoring and hardening--but hit a perplexing issue; want to look at previous commits

* GH-497-TwoInt: finally fixed last problems and cleaned up after me

* GH-497-TwoInt: added integration test for the financials command

* GH-497-TwoInt: multinode test adjustment, changes in documentation

* GH-497-TwoInt: auto review

* GH-497-TwoInt: tests for CLI failing for colors in terminal fixed

* GH-497: sort- exchanged for better order-; changes in wording in docs

* GH-497-TwoInt: an anused import in multinodes

* GH-497-from-sec-review: first portion of repairs

* GH-497-from-sec-review: savepoint before big change...trying to unify column formatted writting of accounts and headings

* GH-497-from-sec-review: simplification with one function covering all types of pretty printed lines

* GH-497-from-sec-review: another portion of minor fixes for FinancialsCommand

* GH-497-from-sec-review: rearranging by meaning group

* GH-497-from-sec-review: fixing financials command

* GH-497-from-sec-review: another small portion of fixes, still operating in financials command

* GH-497-from-second-review: after partial refactoring in big_int_db_processor

* GH-497-from-second-review: still fixes in big_int_db_processor

* GH-497-from-second-review: some more stuff, but at the end moment when deciding if BigIntDivider should return Result (I cannot make my mind up now)

* GH-497-from-second-review: finally progressed on better arragement of tests in the damn challenging file

* GH-497-from-second-review: save point when I realized that relative subtracting at the overflow section won't work this way, I need to specify absolute values

* GH-497-from-second-review: main functionality in big_int_db_processor repaired and new tests written; will have to fix some more things though

* GH-497-from-second-review: more tests running fine; one remaining actually - but I kind of hit the wall here, will see

* GH-497-from-second-review: some more improvement, also still following the suggestions

* GH-497-from-second-review: another big portion of repaired things

* GH-497-from-second-review: more fixes, this time Accountant... a lot about PaymentThresholds

* GH-497-from-second-review: fixed last issues...waiting for another portion from the ongoing review

* GH-497-from-second-review: a fex mixed issue corrections and whole payable_dao fixed

* GH-497-from-second-review: all remaining fixes of the recent batch; gonna wait up more of it

* GH-497-from-sec-review: minor fixes...which tried my will in a day that all just sucked

* GH-497-from-sec-review: various fixes: some of those found in db_mig, and rest...; refactoring in persistent configuration

* GH-497: finished enhancement of the design of Migration configuration etc.; going to attempt to remove the unnecessary create_if_necessary flag

* GH-497-from-second-review: the rest of issues taken care of; stuff around db a lot

* GH-497-from-second-review: this is the commit; I didn't add in all the code, now I do-- the rest of issues taken care of; stuff around db a lot

* GH-497-from-second-review: corrections, all good now, upcoming merge of master

* GH-497-from-third-review: first portion of fixes

* GH-497-from-third-review: another small portion of fixes

* GH-497-from-third-review: another fixes: this time big_int_processor...update with overflow tests

* GH-497-from-third-review: half work done regarding elimination of the heavy floating numbers usage; changing it to use big integers for the slope parameter instead; next will have to fix our defined SQL functions

* GH-497-from-third-review: fixed the slope to be computed as integer, avoiding more expensive translations to f64

* GH-497-from-third-review: few more improvements...in testing user defined sql functions, big_int_db_processor interface and testing user values range limits

* GH-497-from-third-review: nearing the finish line...before the rework of payable_exceeded_threshold

* GH-497-from-third-review: payable_exceeded_threshold got proper test coverage; late but better than never

* GH-497-from-third-review: refactoring macros and arranging less important functions for financials into a smart module

* GH-497-from-third-review: formatting

* GH-497-from-third-review: last changes; clean run

* GH-497-from-fourth-review: fixing the interpretting proces about gwei into MASQ operation; added total supply constant and wrote an integ test to fasten it to the true contract; other optimizations in financials in UI

* GH-497-from-fourth-review: corrected Wei to wei and Gwei to gwei

* GH-497-from-fourth-review: a few more fixes from the review

* GH-497-from-fourth-review: last changes as response to the found issues

* GH-497-from-fourth-review: formatting

* GH-497-from-fourth-review: previous review fully answered

* GH-497-from-fifth-review: previous review fully answered

* GH-497: elevating the code version to 0.7.0

* GH-497-from-fifth-rev: last editor work of the text

* GH-497-sixth-review: fixes from previous reviews

* GH-497: version bump

* GH-497-seventh-review: financials command arranged better into separate files

* GH-497-seventh-review: rearrangement for big int utils in accountant/mod

* GH-497-seventh-review: clippy and fixing an integration test in masq

* GH-497-seventh-review: juss a few details after the review

* v0.7.0_GH-497: last fiddling...passing locally

Co-authored-by: Bert <[email protected]>
Co-authored-by: utkarshg6 <[email protected]>
  • Loading branch information
3 people committed Dec 21, 2022
1 parent 6f517d5 commit 9328225
Show file tree
Hide file tree
Showing 90 changed files with 12,611 additions and 3,008 deletions.
185 changes: 160 additions & 25 deletions USER-INTERFACE-INTERFACE.md
Original file line number Diff line number Diff line change
Expand Up @@ -343,7 +343,7 @@ Another reason the secrets might be missing is that there are not yet any secret
<string>,
<string>, ...
],
"PaymentThresholds": {
"paymentThresholds": {
"debtThresholdGwei": <number>,
"maturityThresholdSec": <number>,
"paymentGracePeriodSec": <number>,
Expand Down Expand Up @@ -392,7 +392,7 @@ database password. If you want to know whether the password you have is the corr
* `earningWalletAddressOpt`: The wallet address for the earning wallet. This is not secret, so
if you don't get this field, it's because it hasn't been set yet.

* `gasPrice`: The Node will not pay more than this number of Gwei for gas to complete a transaction.
* `gasPrice`: The Node will not pay more than this number of gwei for gas to complete a transaction.

* `neighborhoodMode`: The neighborhood mode being currently used, this parameter has nothing to do with descriptors which
may have been used in order to set the Node's nearest neighborhood. It is only informative, to know what mode is running
Expand All @@ -417,7 +417,7 @@ database password. If you want to know whether the password you have is the corr
allowed to remain unpaid, or a pending receivable that won’t cause a ban, decreases linearly from the debtThresholdGwei
to permanentDebtAllowedGwei or unbanBelowGwei.

* `debtThresholdGwei`: Payables higher than this -- in Gwei of MASQ -- will be suggested for payment immediately upon
* `debtThresholdGwei`: Payables higher than this -- in gwei of MASQ -- will be suggested for payment immediately upon
passing the maturityThresholdSec age. Payables less than this can stay unpaid longer. Receivables higher than this
will be expected to be settled by other Nodes, but will never cause bans until they pass the maturityThresholdSec +
paymentGracePeriodSec age. Receivables less than this will survive longer without banning.
Expand All @@ -428,15 +428,15 @@ database password. If you want to know whether the password you have is the corr
* `paymentGracePeriodSec`: A large receivable can get as old as maturityThresholdSec + paymentGracePeriodSec -- in seconds
-- before the Node that owes it will be banned.

* `permanentDebtAllowedGwei`: Receivables this small and smaller -- in Gwei of MASQ -- will not cause bans no matter
* `permanentDebtAllowedGwei`: Receivables this small and smaller -- in gwei of MASQ -- will not cause bans no matter
how old they get.

* `unbanBelowGwei`: When a delinquent Node has been banned due to non-payment, the receivables balance must be paid
below this level -- in Gwei of MASQ -- to cause them to be unbanned. In most cases, you'll want this to be set the
below this level -- in gwei of MASQ -- to cause them to be unbanned. In most cases, you'll want this to be set the
same as permanentDebtAllowedGwei.

* `ratePack`: These four parameters specify your rates that your Node will use for charging other Nodes for your provided
services. They are currently denominated in Gwei of MASQ, but will be improved to allow denomination in Wei units.
services. They are currently denominated in gwei of MASQ, but will be improved to allow denomination in wei units.
These are ever present values, no matter if the user's set any value, they have defaults.

* `exitByteRate`: This parameter indicates an amount of MASQ demanded to process 1 byte of routed payload while the Node
Expand Down Expand Up @@ -595,45 +595,180 @@ field will be null or absent.
##### Correspondent: Node
##### Layout:
```
"payload": {}
"payload": {
"statsRequired": <boolean>,
"topRecordsOpt": <optional {
"count": <positive integer>,
"orderedBy": <string>
}>,
"customQueriesOpt": <optional {
"payableOpt" : <optional {
"minAgeS": <positive integer>,
"maxAgeS": <positive integer>,
"minBalanceGwei": <positive integer>,
"maxBalanceGwei": <positive integer>
}>,
"receivableOpt": <optional {
"minAgeS": <positive integer>,
"maxAgeS": <positive integer>,
"minBalanceGwei": <positive integer>,
"maxBalanceGwei": <positive integer>
}>
}>
}
```
##### Description:
Requests financial statistics from the Node.
This command requests financial statistics from the Node. Without any parameters specified, it produces a brief summary
of financial information; but the output can be customized to show more details.

The details can bear on two different account types stored in two tables of the persistent database. Those types are
payables and receivables.

One option to get more information about them is a query of the top N records from these financial tables, ordered by
one's preferences, either by balance or age. This command setup always returns two sets of accounts, one set for each
type.

In a different query mode, the user provides a customized query for either payables or receivables or both. The user
will be requested to specify ranges of age and balance to constrain the result set.

The limits for the age range can vary from 0 (as recent as possible) to 9,223,372,036,854,775,807 seconds ago (well
beyond any reasonable scientific estimate of the age of the universe). The limits for the balance range are similarly
generous, except that receivable balances can be negative as well as positive.

It needs to be stated that each mode excludes the other one.

While statistics has been considered the foundation of this command, it reports back structured information about
the Node's historical financial operations. This will include services ordered from other Nodes as well as the opposite,
services provided for other Nodes, represented by monetary values owed and paid to and from this Node's wallets.

`statsRequired` should be true if historical total balances (see below) are required, false if they are not necessary.
If topRecordsOpt and customQueriesOpt are both null, statsRequired must not be false, since it would produce an empty
response otherwise.

`topRecordsOpt` initiates the request for a given number of top accounts from the tables. An optional feature.
It is important to note that only accounts with positive balances can be displayed by this mode. Some values might stay
out of scope since there might be cases where receivable balances are negative.

`count` is the maximum number of records to be returned. It should be a number between 1 and 65535, inclusive.

`orderedBy` allows you to choose whether the results are sorted in descending order either by `Balance` or `Age`.
It is compulsory to use at least one parameter.

`customQueriesOpt` provides another way to get a subset of accounts, this time by more specific metrics. It works for
both account types, payables and receivables. Possibly only one of them is queried. This query responds well also for
balances with negative values, and therefore this is a good fit for a complete check of receivable accounts going
possibly negative.

`payableOpt` is an optional field with values that configure the customized search for payables. It holds four numbers
that define two ranges of balance and age used as the scope of the search.

`receivableOpt` is an optional field with values that configure the customized search for receivables. It holds four
numbers that define two ranges of balance and age used as the scope of the search.

Both `payableOpt` and `receivableOpt` are complex structures containing four subfields. There is a number in each of
these subfields that represents the end point of the range of either balance or age. Regarding the names of the
subfields, both structures are identical. The only difference lies in the values that the balance parameters can take
on. While receivables are valid between -9223372036854775808 and 9223372036854775807, payables only between 0 and
9223372036854775807.

`minAgeS` is measured in seconds before the present time and sets a time constraint for the accounts we will be
searching over; this is the lower limit for the debt's age, or how long it has been since the last payment.

`maxAgeS` is measured in seconds before the present time and sets a constraint for the accounts we will be
searching over; this is the upper limit for the debt's age, or how long it has been since the last payment.

This request will report back information about a Node's historical financial operations. This will include both
services ordered from other Nodes and services provided for other Nodes, represented as monetary values owed and
paid to and from this Node's wallets.
`minBalanceGwei` is represented as an amount of gwei. Any records with balance below this value will not be returned.

`maxBalanceGwei` is represented as an amount of gwei. Any records with balance above this value will not be returned.

#### `financials`
##### Direction: Response
##### Correspondent: Node
##### Layout:
```
"payload": {
"totalUnpaidAndPendingPayable": <integer>
"totalPaidPayable": <nonnegative integer>
"totalUnpaidReceivable": <integer>
"totalPaidReceivable": <nonnegative integer>
"statsOpt": <optional {
"totalUnpaidAndPendingPayableGwei": <nonnegative integer>
"totalPaidPayableGwei": <nonnegative integer>
"totalUnpaidReceivableGwei": <integer>
"totalPaidReceivableGwei": <nonnegative integer>
}>,
"queryResultsOpt":<optional {
"payableOpt": [
{
"wallet": <string>,
"ageS": <integer>,
"balanceGwei": <integer>,
"pendingPayableHashOpt": <optional string>
},
[...]
],
"receivableOpt": [
{
"wallet": <string>,
"ageS": <integer>,
"balanceGwei": <integer>
},
[...]
]
}>
}
```
##### Description:
Contains the requested financial statistics.
Contains the requested financial statistics or subsets (views) of the database tables and their records.

`statsOpt` provides a collection of metrics on services consumed and provided. The current span of the tracked data
is since the start of the still running Node. Later on, we'd like to change it to all-time values.

`totalUnpaidAndPendingPayable` is the number of Gwei we believe we owe to other Nodes and that those other Nodes have
not yet received, as far as we know. This includes both bills we haven't yet paid and bills we have paid, but whose
`totalUnpaidAndPendingPayableGwei` is the number of gwei we believe we owe to other Nodes and that those other Nodes
have not yet received, as far as we know. This includes both bills we haven't yet paid and bills we have paid, but whose
transactions we have not yet seen confirmed on the blockchain.

`totalPaidPayable` is the number of Gwei we have successfully paid to our creditors and seen confirmed during the time
the current instance of the Node has been running. In the future, this number may become cumulative over more time than
just the current Node run.
`totalPaidPayableGwei` is the number of gwei we have successfully paid to our creditors and seen confirmed.

`totalUnpaidReceivable` is the number of Gwei we believe other Nodes owe to us, but have not yet been included in
`totalUnpaidReceivableGwei` is the number of gwei we believe other Nodes owe to us, but have not yet been included in
payments we have seen confirmed on the blockchain. This includes both payments that have never been made and also
payments that have been made but not yet confirmed.

`totalPaidReceivable` is the number of Gwei we have successfully received in confirmed payments from our debtors during
the time the current instance of the Node has been running. In the future, this number may become cumulative over more
time than just the current Node run.
`totalPaidReceivableGwei` is the number of gwei we have successfully received in confirmed payments from our debtors.

`queryResultsOpt` with no respect to which mode of record retrieval was requested, this is always the field that will
hold the records found. If there are no records matching the query, the response will bring an empty array.

If the `topRecords` parameter is used, the results will be sorted in descending order by either balance or age,
depending on the value of the orderedBy parameter. The number of results returned will be no greater than the value
of the `topRecords` parameter.

With `customQueryOpt`, the limiting age and balance ranges depend on the user's choices and constrain the subset of
records being returned. The results are always ordered by balance in this mode, and it is the case here too, that
an empty array is handed back if no records can be retrieved.

This query mode is just optional, and it is also a valid option to request just a single table view. Therefore, null
should be anticipated at various places, either at the position of individual tables (`payableOpt`, `receivableOpt`)
or in place of the whole thing (`customQueryOpt`), which implies that a command with these arguments was not used.

`payableOpt` is the part referring to payable records if any exist, null or an empty array are also possible.

`wallet` is the wallet of the Node that we owe to.

`ageS` is a number of seconds that elapsed since our payment to this particular Node was sent out last time, and the
payment was later also confirmed on the blockchain.

`balanceGwei` is a number of gwei we owe to this particular Node.

`pendingPayableHashOpt` is present only sporadically. When it is, it denotes that we've recently sent a payment to the
blockchain, but our confirmation detector has not yet determined that the payment has been confirmed. The value is
either null or stores a transaction hash of the pending transaction.

`receivable` is the field devoted to receivable records if any exist.

`wallet` is the wallet of the Node that owes money to us for the services we provided to this Node in the past.

`age` is a number of seconds that elapsed since this particular debtor made the last payment to our account in order to
redeem his liabilities.

`balanceGwei` is a number of gwei that this debtor owes to us.


#### `generateWallets`
##### Direction: Request
Expand Down
4 changes: 2 additions & 2 deletions automap/Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion automap/Cargo.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[package]
name = "automap"
version = "0.6.2"
version = "0.7.0"
authors = ["Dan Wiebe <[email protected]>", "MASQ"]
license = "GPL-3.0-only"
copyright = "Copyright (c) 2019-2021, MASQ (https://masq.ai) and/or its affiliates. All rights reserved."
Expand Down
4 changes: 2 additions & 2 deletions dns_utility/Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion dns_utility/Cargo.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[package]
name = "dns_utility"
version = "0.6.3"
version = "0.7.0"
license = "GPL-3.0-only"
authors = ["Dan Wiebe <[email protected]>", "MASQ"]
copyright = "Copyright (c) 2019, MASQ (https://masq.ai) and/or its affiliates. All rights reserved."
Expand Down
7 changes: 6 additions & 1 deletion masq/Cargo.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[package]
name = "masq"
version = "0.6.3"
version = "0.7.0"
authors = ["Dan Wiebe <[email protected]>", "MASQ"]
license = "GPL-3.0-only"
copyright = "Copyright (c) 2019, MASQ (https://masq.ai) and/or its affiliates. All rights reserved."
Expand All @@ -18,13 +18,18 @@ itertools = "0.8.0"
lazy_static = "1.4.0"
linefeed = "0.6.0"
masq_lib = { path = "../masq_lib" }
num = "0.4.0"
regex = "1.5.4"
thousands = "0.2.0"
websocket = {version = "0.26.2", default-features = false, features = ["sync"]}
ctrlc = "3.2.1"

[target.'cfg(not(target_os = "windows"))'.dependencies]
nix = "0.23.0"

[dev-dependencies]
atty = "0.2.14"

[lib]
name = "masq_cli_lib"
path = "src/lib.rs"
Expand Down
32 changes: 31 additions & 1 deletion masq/src/command_factory.rs
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,10 @@ impl CommandFactory for CommandFactoryReal {
Err(msg) => return Err(CommandSyntax(msg)),
},
"descriptor" => Box::new(DescriptorCommand::new()),
"financials" => Box::new(FinancialsCommand::new()),
"financials" => match FinancialsCommand::new(pieces) {
Ok(command) => Box::new(command),
Err(msg) => return Err(CommandSyntax(msg)),
},
"generate-wallets" => match GenerateWalletsCommand::new(pieces) {
Ok(command) => Box::new(command),
Err(msg) => return Err(CommandSyntax(msg)),
Expand Down Expand Up @@ -367,6 +370,33 @@ mod tests {
);
}

#[test]
fn complains_about_financials_command_with_bad_syntax() {
let subject = CommandFactoryReal::new();

let result = subject
.make(&[
"financials".to_string(),
"--make-me-rich".to_string(),
"slowly".to_string(),
])
.err()
.unwrap();

let msg = match result {
CommandSyntax(msg) => msg,
x => panic!("Expected syntax error, got {:?}", x),
};
assert_eq!(msg.contains("Found argument"), true, "{}", msg);
assert_eq!(msg.contains("--make-me-rich"), true, "{}", msg);
assert_eq!(
msg.contains("which wasn't expected, or isn't valid in this context"),
true,
"{}",
msg
);
}

#[test]
fn testing_command_factory_with_good_command() {
let subject = CommandFactoryReal::new();
Expand Down
Loading

0 comments on commit 9328225

Please sign in to comment.