[bisq-network/bisq] Update api beta test guide: add 'editoffer' (#5577)

[Stan]

> I just recognized when creating a new offer in the response the enabled state is displayed wrong:

Some async tasks (fully preparing and publishing a new offer) do not finish in time to be included in the server's response to the CLI.  The `OpenOffer.State {AVAILABLE, ... DEACTIVATED)` is one bit of information the CLI does not get from the server in the `createoffer` response because the new `OpenOffer` instance has not yet been added to the `OpenOfferManager`.   

I didn't want to lie about the true `Enabled` state in the `createoffer` response, that's why you see `NO`.
But as you see,  calling `getmyoffer` right after `createoffer` shows the correct `Enabled` state `YES`.



> It says NO, but it is visible to the other peer already. When requesting the state of the specific offer it does display the correct value.

The CLI is session-less, it only knows that at the instance of offer creation, no `OpenOffer.STATE` is ready to be passed to the CLI.  By the time you become annoyed at seeing `Enabled`=`NO`, the `OpenOffer` has been added to the `OpenOfferManager` and is published to other peers.  About 1-3 seconds after you successfully call `createoffer`, the correct `Enabled` value shows up in your `getmyoffer` console output.

Not great.  Would you prefer that the CLI block on `createoffer` until the `OpenOfferManager` has the new `OpenOffer` object?  That did not seem like a good idea before now, and still doesn't... what do you think?


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/5577#issuecomment-880747188
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20210715/05104105/attachment.htm>