Add LongRunningTradesTest to apitest #5303
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Add PRICE_CHECK_FAILED to enum AvailabilityResult. - Add enum AvailabilityResult to TakeOfferReply message.
- GrpcErrorMessageHandler A new ErrorMessageHandler implementation to get around the api specific problem of having to use Task ErrorMessageHandlers that build task error messages for the UI. - GrpcExceptionHandler A new method for working with the ErrorMessageHandler interface. - GrpcTradesService, CoreApi, CoreTradesService: Ajdusted takeoffer error handling to give a failure reason provided by the new GrpcErrorMessageHandler.
Add debugging convenience to core.api.model.TxInfo.
This new api testcase can run long series' of regtest trades by looping over modified TakeBuyBTCOfferTest and TakeSellBTCOfferTest cases. The purpose is to help reproduce problems and isolate bugs Bisq's core and api layers. LongRunningTradesTest is not enabled by default; it will not run in a default test environment (such a Travis CI). Enviornment variable LONG_RUNNING_TRADES_TEST_ENABLED must exist for the test to run. The env variable can be set in a bash shell before running the test case in a shell (using a gradle command), or the environment variable can be set in an Intellij test launcher's Evironment variables field. The modifed (short running) TakeBuyBTCOfferTest and TakeSellBTCOfferTest cases run as before. Changes include: - Add static boolean isLongRunningTest to AbstractOfferTest. - Add looping control Supplier maxTradeStateAndPhaseChecks to AbstractTradeTest. It uses the isLongRunningTest flag in the superclass to help define the wait times for trade state/phase changes during short and long running tests. - Made AbstractTradeTest assert(true, trade.isDepositPublished) conditional upon isLongRunningTest value. Long running trade test asserts have to be looser due to increasing latency of wallet, offer and trade operations in the server as the trade counts increase. - Overload ApiTestCase#startSupportingApps with additional flag: startSupportingAppsInDebugMode. Default is false. This makes starting background apps in debug mode a bit more convenient and self explanatory.
- Add description msg TakeOfferReply proto, and fromProto method to core.offer.enum AvailabilityResult. The description field maps a client usable error message to the enum. - Adjust GrpcErrorMessageHandler to add AvailabilityResult.description() to takeoffer reply. - Refactor (split up) GrpcClient's takeOffer. Add getTakeOfferReply() to give clients a chance to make choices based on the reply's AvailabilityResult when the takeoffer command did not result in a trade. (Some errors are fatal, some not.)
|
I hope some of the other devs will help resolve this issue. To run the test case, clone this branch and run
|
This change uses recently added walletService.isAddressUnused to ensure the api's CoreWalletsService creates an unused address if none exists. - grpc.proto: Add bool isAddressUnused field to message AddressBalanceInfo. - AddressBalanceInfo: Adjust AddressBalanceInfo proto wrapper. - CoreWalletsService: Use walletService.isAddressUnused in getFundingAddresses. - GrpcClient: Adjust to modified AddressBalanceInfo. - TableFormat, ColumnHeaderConstants: Add 'Is Used' column to getfundingaddresses output. Note: bugfix is out of scope for this PR, but the test case helped expose this bug.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This new api testcase can run a long series of regtest trades by looping over modified
TakeBuyBTCOfferTestandTakeSellBTCOfferTestcases. The purpose is to help reproduce problems and isolate bugs Bisq's core and api layers.LongRunningTradesTestis not enabled by default; it will not run in a default test environment (such a Travis CI). Enviornment variableLONG_RUNNING_TRADES_TEST_ENABLEDmust exist for the test to run. The env variable can be set in a bash shell before running the test case in a shell (using a gradle command), or the environment variable can be set in an Intellij test launcher'sEnvironment variablesfield.The modifed (short running)
TakeBuyBTCOfferTestandTakeSellBTCOfferTestcases run as before.Changes include:
Add
static boolean isLongRunningTesttoAbstractOfferTest.Add looping control Supplier
maxTradeStateAndPhaseCheckstoAbstractTradeTest. It uses theisLongRunningTestflag in the superclass to help define the wait times for trade state/phase changes during short and long running tests.Made
AbstractTradeTest assert(true, trade.isDepositPublished)conditional uponisLongRunningTestvalue. Long running trade test asserts have to be looser due to increasing latency of wallet, offer and trade operations in the server as the trade counts increase.Overload
ApiTestCase#startSupportingAppswith additional flag:startSupportingAppsInDebugMode. Default is false. This makes starting background apps in debug mode a bit more convenient and self explanatory.PR #5302 should be reviewed/merged before this one.