These are failing on the tip of release/1.5.0 currently due to extra
validation added to PersistenceManager, causing the build to fail upon
merging upstream. Add missing PersistenceManager.shutDown calls to the
tearDown methods of the affected tests to fix.
We need to set addDecryptedDirectMessageListener without
delay as otherwise we could miss direct messages (detected
with localhost testing, with tor its likely slower and
would not have been triggered).
This is not really needed as we call it at each state change of the
trade but gives more redundancy in case we missed one or once
changes are applied and a dev forgets to call it.
Multiple repeated calls do have close to zero costs.
The deposit confirmed state is set after we applied the mailbox messages,
which led to a task failure due wrong phase and the message was not applied.
Further it can be that the wallet is still syncing and the deposit
confirmed state is set in any time in the future.
To fix the first problem we add a bit of delay so that the trade has
been updated when we apply the mailbox messages. A better fix would be to change
the order of the methods but that is a bit tricky to get right and I dont want to
risk that for that release.
The second problem would require a large change to trigger the mailbox
processing based on wallet state. We prefer to be more tolerant with
the expected phase instead so allow the mailbox message to be processed
also in the DEPOSIT_PUBLISHED state.
This has no risks as the payout tx would be invalid anyway if the
buyer has cheated and sent the msg in not confirmed deposit tx state (only
possible with code manipulation).
A better fix would to add a listener for the wallet and process
the mailbox msg once wallet is ready and trade state set, but I
leave that for another PR.
In the CLI, this method now takes a single argument, the path to a json
file (a payment account form). The json text is read from the file
and sent to the server, where it is serialized to a new PaymentAccount
instance, saved, and sent back to the CLI as a protobuf.PaymentAccount.
- Modified existing gRPC boilerplate in grpc.proto and GrpcPaymentAccountsService.
- Modified existing method signatures in CoreApi and CorePaymentAccountsService.
- Replaced existing method impl in CorePaymentAccountsService and
removed dead code.
- Replaced the CLI's existing 'createpaymentacct' method impl.
- Modified existing tests.
This class uses the gson PaymentAccountTypeAdapter to generate editable
json forms for PaymentAccount sub-types, and instantiate PaymentAccount
instances from edited json forms.
Changed the core getPaymentMethods() -> getFiatPaymentMethods() to avoid
"Unnecessary use of fully qualified name 'PaymentMethod.getPaymentMethods'
due to existing static import 'bisq.core.payment.payload.PaymentMethod.*'"
Had to change the getPaymentMethods() names to getPaymentMethodIds() to
avoid this codacy issue:
"Unnecessary use of fully qualified name 'PaymentMethod.getPaymentMethods'
due to existing static import 'bisq.core.payment.payload.PaymentMethod.*'"
If 'PaymentMethod.getPaymentMethods' was changed to 'getPaymentMethods',
a recursive loop would result, ending in an out of stack heap crash.
This renaming of the method on the server is correct, but the CLI's
'getpaymentmethods' name was not changed.
Returns a list of supported payment method IDs. This gives CLI users
the correct payment method id for creating a new payment account.
- Added gRPC service GetPaymentMethods to grpc.proto.
- Added gRPC boilerplate method to GrpcPaymentAccountsService.
- Added implimentation to CoreApi -> CorePaymentAccountsService.
- Refactored PaymentAccountTest hierarchy.
- Add api method to CLI.
We relied on the shutdwon routine to be called reliably but it seems that is not the case as some bug reports show.
So we call requestPersistence at every write access of the trade object
We saw that some seed nodes have 2 filters after filter update.
This should not be the case as the remove is broadcast before the
add but seems there is some issue in the P2P storage which does
not cover that correctly.
By adding a 5 sec delay between the remove and add we mitigate
that issue, though should be fixes in the P2P layer but that
will be a more complex and larger effort.
Seems the persistence at shutdown is too unsafe and we got bug reports where data was missing.
https://github.com/bisq-network/bisq/issues/4806
Use millisec instead of sec for delay
Rename delayInSec to delay
Showing 'x' days until limits lifted (signed, pending)
Showing clock icon (signed, pending)
Showing outlined check icon (aging accounts)
Showing account age (unsigned or aging)
Changed column name from 'Signed since' to 'Account info'
Fixed bug when switching between altcoins and fiat order books
the account info column was being added back to the table in
the wrong position.
This change fixes the recently bloated wallet balances api. Now there
is one CLI getbalance [bsq|btc] method that calls a getbalances(currency-code)
on the server. The server returns full wallet balance information for
BSQ, BTC, or both if the CLI's currency argument is absent.
- grpc.proto: Reduced number of getbalance(s) proto services from
four to one.
- GrpcWalletsService: Reduced number of getbalance(s) gRPC service
boilerplate methods from four to one.
- CoreApi, CoreWalletsService: Reduced number of getbalance(s) gRPC
service implementation methods from four to one.
- CliMain: Reduced number of getbalance(s) commands from four to one.
- BalancesInfo: Changed BsqBalanceInfo & BtcBalanceInfo field names
to bsq and btc, respectively, to make calling their accessors
more readable, less verbose.
- BtcBalanceInfo, BsqBalanceInfo: Defined static final EMPTY instances
as place holders in a BalancesInfo returned by the gRPC server, when
one or the other balance types is not requested. Would be nice
to serve Optional.empty() instead, but protobuf does not support
it or null.
- Adjusted affected api tests and build doc.
