Insufficient liquidity error warning is confusing when liquidity still exists

[dib542]

It appears that the error for "There is no liquidity to complete this transaction (code: 1114)" is a message that occurs whenever amountOut does not pass the minOut check. This confused me for a long while because I was sometimes able to reproduce this "insufficient liquidity" error and did not realise it was directly dependant on the requested minOut parameter, because I thought the amount of liquidity would not be related to minOut.

When this check fails and there are no more ticks of liquidity available I think this is a good error to display. But when there is clearly enough liquidity remaining in the pair this message is very confusing and unhelpful because it does not let me know that if I adjusted my minOut value the swap could be successful. Something like "Requested swap does not return more than minimum amount out specified at this time" would be helpful (depends on minOut and market movements): even for the case of not enough liquidity left to complete the transaction, because this message would let the user know that if they reduced their minOut parameter to 0 then they would be able to extract out the last remaining available liquidity of the token pair.

minimal reproducer:

• from commit (https://github.com/duality-labs/duality/commit/fe4e309ecbe49b577e631dfe8c9ad25c862ed1f5)
• have docker installed and use this in a CLI in the repo folder

  docker build -t localtest --build-arg NETWORK=duality-testnet-1 .
  docker run -it --rm -e LOG_LEVEL=warn -p 26656:26656 -p 26657:26657 -p 26658:26658 -p 1317:1317 -p 6060:6060 -p 9090:9090 -p 9091:9091 -e MODE=new -e MNEMONIC="pull drill around mandate trigger loud art hungry robot sting thumb funny syrup gown urban repair damp story sense novel flag person melody sudden" localtest

• in a separate terminal window enter the docker container

  $ docker exec -it $(docker ps -q --filter="ancestor=localtest") sh

• run following commands

  
  #!/bin/bash

deposit 1000 stake in one liquidity pool: price of 1 stake/token

dualityd tx dex deposit -y --from custom-user --keyring-backend test --broadcast-mode block -- cosmos12klznq6thpjtw7fwk4ukqly2spwea8dg7gll9k stake token 1000 0 0 0

attempt to swap 100 stake for 100 token (not possible because there is a 0.01% fee here, 99.99 token is possible)

- error is unexpected code 1114 (failed to execute message; message index: 0: There is no liquidity to complete this transaction)

dualityd tx dex swap -y --from custom-user --keyring-backend test --broadcast-mode block cosmos12klznq6thpjtw7fwk4ukqly2spwea8dg7gll9k 100 stake token token 100

- the error claims "no liquidity" when there is clearly liquidity existing and enough liquidity to complete the trade

---

What this actually looks like in some scenarios on the front end:

When requesting 0.9 STK from a tick pair that contains 50 STK of liquidity I get the error: "There is no liquidity to complete this transaction"
![Screenshot 2022-12-06 at 12 44 39 pm](https://user-images.githubusercontent.com/6194521/205801878-e7e093ab-cfe4-4ad5-a214-6b4ba80a7a4b.png)

If I adjust the minimum amount out (using slippage tolerance control to 50%) the transaction is able to pass (not intended UX, separate UX issue to fix the minimum amount out calculation on the front end https://github.com/duality-labs/duality-web-app/issues/214):
![Screenshot 2022-12-06 at 12 46 20 pm](https://user-images.githubusercontent.com/6194521/205801909-2c23d8ec-8ebc-4f90-8b5b-d56af7ff864a.png)

extended reproducer from my actual frontend interactions:
```sh
#!/bin/bash

# deposit 50 STAKE in one liquidity pool: price of 1.10 stake/token
dualityd tx dex deposit -y --from custom-user --keyring-backend test --broadcast-mode block -- cosmos12klznq6thpjtw7fwk4ukqly2spwea8dg7gll9k stake token 50000000000000000000 0 -953 2

# deposit 50 STAKE in one liquidity pool: price of 1.11 stake/token
dualityd tx dex deposit -y --from custom-user --keyring-backend test --broadcast-mode block -- cosmos12klznq6thpjtw7fwk4ukqly2spwea8dg7gll9k stake token 50000000000000000000 0 -1044 2

# swap 50 TOKEN in one liquidity pool = 45.319 STAKE (gas used: 99312)
dualityd tx dex swap -y --from custom-user --keyring-backend test --broadcast-mode block cosmos12klznq6thpjtw7fwk4ukqly2spwea8dg7gll9k 50000000000000000000 stake token token 0

# swap 5 TOKEN in one liquidity pool = 4.5319 STAKE (cumulative 49.85 STAKE almost drained one pool) (gas used: 99461)
dualityd tx dex swap -y --from custom-user --keyring-backend test --broadcast-mode block cosmos12klznq6thpjtw7fwk4ukqly2spwea8dg7gll9k 5000000000000000000 stake token token 0

# there are now 2 liquidity pools
# - one at 1.10 stake/token containing 55 TOKEN, 0.15 STAKE
# - one at 1.11 stake/token containing  0 TOKEN,   50 STAKE

# attempt to swap 1 TOKEN across two liquidity pools but fail due to increased gas cost (gas required: 298691)
# - error is expected, code 11 (out of gas in location: ReadFlat; gasWanted: 200000, gasUsed: 200151: out)
dualityd tx dex swap -y --from custom-user --keyring-backend test --broadcast-mode block cosmos12klznq6thpjtw7fwk4ukqly2spwea8dg7gll9k 1000000000000000000 stake token token 901849497412440208

# add enough gas and you will see the error here:
# - error is unexpected code 1114 (failed to execute message; message index: 0: There is no liquidity to complete this transaction)
dualityd tx dex swap -y --from custom-user --keyring-backend test --broadcast-mode block cosmos12klznq6thpjtw7fwk4ukqly2spwea8dg7gll9k 1000000000000000000 stake token token 901849497412440208 --gas 2000000

# send a request with the actual possible amount out (rounded down) here and the request will succeed
dualityd tx dex swap -y --from custom-user --keyring-backend test --broadcast-mode block cosmos12klznq6thpjtw7fwk4ukqly2spwea8dg7gll9k 1000000000000000000 stake token token 899521045718865077 --gas 2000000

[itamarreif]

Seems the issue is that ErrNotEnoughLiquidity (code 1114) is used for both:

• no ticks in the swap direction 0to1, 1to0
• slippage limit reached 0to1, 1to0

These two cases seem to be slippage errors and adding more specific error description for the above case should resolve.