Returns name of the BTC network API daemon is connected to.
I am working on some Java bot examples in another repo, and want to stop
worrying about accidentally simulating trade payments on mainnet, despite
all the warnings I add in comments. The 'getnetwork' method allows bots
to know what network the API daemon is connected to, and gives API bot
devs and users a way to avoid one potential source of costly mistakes.
API CLI manpage and apitest case are included in this commit.
This API bug was relying on offer availability checks, but those do
not check the taker's wallet. The take offer model makes the check convenient,
and a core.api NotAvailableException can be thrown from CoreTradesService,
then mapped to the appropriate gPRC UNAVAILABLE exception sent to clients.
A new test case is added for this change: Bob's wallet is emptied, he
fails to take an offer, and Alice returns Bob's BTC.
Non-CLI clients need a better way of accessing payment details
than a contract json string.
- Add grpc.proto PaymentAccountPayloadInfo field: payment_details.
- Adjust proto wrapper PaymentAccountPayloadInfo to new field.
- Add test asserts to verify payment details are sent to client.
- Fix a test name: testKeepFunds -> testCloseTrade.
Based on branch `master` @ Sat 12 Mar 2022 01:42 PM -03 ,
commit c6293b5273
I think this bug was introduced when deprecating GrpcOffersService
.getMyOffer(id), in favor of using only getOffer(id) for 'my'
and 'available' offers. This change explicitly sets the proto's
isActivated flag in the OfferInfo factory methods, and adds checks
to api offer test cases.
Based on branch `2-improve-grpc-exception-status-code-mapping`,
PR https://github.com/bisq-network/bisq/pull/6088
Exceptions thrown by the core.api services for the daemon Grpc*Services
have to be converted into gRPC StatusRuntimeExceptions before being sent to
gRPC clients. Most of these gRPC StatusRuntimeExceptions had a gRPC
Status.Code.UNKNOWN, which not helpful to client error handlers.
This change partially resolves the issue by sending more meaningful
io.grpc.Status.Codes to clients, where possible. But it is not as
comprehensive as it an be for a webapp because HTTP has so many more
possible response status codes than the gRPC library (sixteen). See:
https://github.com/grpc/grpc-java/blob/master/api/src/main/java/io/grpc/Status.java
There are three types of changes:
- Create custom exceptions in bisq.core.api.exception.
- Map any custom bisq.core.api.exception to a meaningful
io.grpc.Status.Code within daemon Grpc*Service classes.
- Adjust apitest cases to new grpc status codes.
Based on branch `move-cli-crypto-offer-filter-to-server`, PR https://github.com/bisq-network/bisq/pull/6086
Some API reference & Python bot examples exposed an API bug the Java CLI
has been hiding. Due due this Bisq v1 Offer entity design:
- In fiat offers, the baseCurrencyCode=BTC, counterCurrencyCode=FiatCode
- In altcoin offers, baseCurrencyCode=AltcoinCode, counterCurrencyCode=BTC,
new API examples were not doing what the CLI has been doing for several
months, which is get (cryptocurrency) all BTC offers from the server,
and filter on the altcoin code. The CLI side filtering should have been
done on the server, as it is in this commit.
A lot of dead gRPC client side offer filtering code is removed as well.
Based on `master`.
