Bisq daemon loosing DAO consensus

Hi,

after taking (at least one) offer via the Bisq daemon API, taking another offer (after a grace period of 20min) might yield the following error:

Nov-22 12:18:44.354 [BisqDaemonMain] INFO b.common.taskrunner.TaskRunner: Run task: ProcessOfferAvailabilityResponse
Nov-22 12:18:44.355 [BisqDaemonMain] ERROR bisq.common.taskrunner.Task: An error occurred at task: ProcessOfferAvailabilityResponse
Cannot take offer because snapshot height does not match. Probably your DAO data are not synced.
Nov-22 12:18:44.355 [BisqDaemonMain] ERROR b.common.taskrunner.TaskRunner: Task failed: ProcessOfferAvailabilityResponse / errorMessage: An error occurred at task: ProcessOfferAvailabilityResponse
Cannot take offer because snapshot height does not match. Probably your DAO data are not synced.
Nov-22 12:18:44.356 [BisqDaemonMain] ERROR b.c.o.a.OfferAvailabilityProtocol: An error occurred at task: ProcessOfferAvailabilityResponse
Cannot take offer because snapshot height does not match. Probably your DAO data are not synced.
Nov-22 12:18:44.356 [BisqDaemonMain] ERROR bisq.core.offer.Offer: An error occurred at task: ProcessOfferAvailabilityResponse
Cannot take offer because snapshot height does not match. Probably your DAO data are not synced.
Nov-22 12:18:44.356 [BisqDaemonMain] ERROR b.d.grpc.GrpcTradesService: An error occurred at task: ProcessOfferAvailabilityResponse
Cannot take offer because snapshot height does not match. Probably your DAO data are not synced.
Nov-22 12:18:44.358 [BisqDaemonMain] ERROR b.d.grpc.GrpcTradesService: java.lang.IllegalArgumentException: Could not find an AvailabilityResult in error message:
An error occurred at task: ProcessOfferAvailabilityResponse
Cannot take offer because snapshot height does not match. Probably your DAO data are not synced.
at bisq.daemon.grpc.GrpcErrorMessageHandler.lambda$getAvailabilityResult$1(GrpcErrorMessageHandler.java:133)
at java.base/java.util.Optional.orElseThrow(Optional.java:403)
at bisq.daemon.grpc.GrpcErrorMessageHandler.getAvailabilityResult(GrpcErrorMessageHandler.java:131)
at bisq.daemon.grpc.GrpcErrorMessageHandler.getAvailabilityResultWithDescription(GrpcErrorMessageHandler.java:120)
at bisq.daemon.grpc.GrpcErrorMessageHandler.handleTakeOfferError(GrpcErrorMessageHandler.java:103)
at bisq.daemon.grpc.GrpcErrorMessageHandler.handleErrorMessage(GrpcErrorMessageHandler.java:82)
at bisq.daemon.grpc.GrpcTradesService.lambda$takeOffer$3(GrpcTradesService.java:128)
at bisq.core.offer.Offer.lambda$checkOfferAvailability$1(Offer.java:168)
at bisq.core.offer.availability.OfferAvailabilityProtocol.handleTaskRunnerFault(OfferAvailabilityProtocol.java:166)
at bisq.core.offer.availability.OfferAvailabilityProtocol.lambda$handleOfferAvailabilityResponse$4(OfferAvailabilityProtocol.java:131)
at bisq.common.taskrunner.TaskRunner.handleErrorMessage(TaskRunner.java:91)
at bisq.common.taskrunner.Task.failed(Task.java:73)

I have taken some 100 offers earlier without issues, but since around two weeks this happens constantly. After shutting down the deamon and starting the desktop GUI, there is no DAO mismatch, instead it reports “Your local node is in consensus with the network”.

Is there any way to check the DAO state in the API before taking an offer? How can the daemon loose consensus on the DAO state?

Thanks for your help, Bernd.

are you still experiencing this now? there was a seed node having issues, which has recently been restarted

I am still testing:

(1) the desktop now seems to have no DAO state issues any more (before it was in consensus with the seed nodes most of the time, but half of the peers were in conflict).

(2) I restarted the daemon and run the trading app (without taking offers). Until now (running for a few hours), all seems good too - but I am cautious and will run without taking trades for some more time and report back later.

you probably were just suffering from the issue with the outofsync seednode

Yes, problem seems to be solved - the trading bot ran for 24h without issues.

One question remains: is there any way to detect a DAO consensus mismatch from within the API, so the app can (at least) stop operations and start a DAO resync? That would be very helpful. If that will not be feasible in v1, I am eagerly awaiting v2…

not that I know of actually, but you can check with the api development repo at GitHub - bisq-network/bisq-api-reference: Bisq API Reference Doc Generator