tecPATH_DRY - Take a look at my JSON object

Technical questions about the Ripple API, the protocol, etc.

tecPATH_DRY - Take a look at my JSON object

Postby virajkamat » Mon Mar 21, 2016 10:43 am

I'm receiving a techPATH_DRY error, could not send partial amount it seems. What have I missed out in my payment JSON object.

The rippleClient Application works fine with the amount I've specified here but then why is the API call failing ????

var maxAmountSend = (sentExchangeRate*0.00037).toString();

const payment = {
source: {
address: address,
maxAmount: {
value: maxAmountSend,
currency: 'USD',
counterparty:'rLEsXccBGNR3UPuPu2hUXPjziKC3qKSBun'
}
},
destination: {
address: 'r9GD5ChpfAXo3nm4P46vL499fuK6DGRWgT',
amount: {
value: '0.00037',
currency: 'EUR',
counterparty:'rLEsXccBGNR3UPuPu2hUXPjziKC3qKSBun'
}
},
limitQuality:true
};
virajkamat
 
Posts: 19
Joined: Wed Mar 09, 2016 8:29 am

Re: tecPATH_DRY - Take a look at my JSON object

Postby twarden » Mon Mar 21, 2016 2:43 pm

You may want to use the delivered_amount field to attempt to solve this issue. Here is the list of error results. tecPATH_DRY means the transaction failed because the provided paths did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by trust lines. You may also want to look over the Partial Payments documentation:

Partial Payments Warning

When the tfPartialPayment flag is enabled, the Amount field is not guaranteed to be the amount received. The delivered_amount field of a payment’s metadata indicates the amount of currency actually received by the destination account. When receiving a payment, use delivered_amount instead of the Amount field to determine how much your account received instead.
XAGATE Thread~QGK

Robbieboy2 wrote:I think datz is the right man to answer this.
pigeons wrote:That's exactly what I was thinking as I read this!


Don't worry! I'm pretty sure that I got this under control, the last crazy visionary was was far too insane, but I struck the correct balance.
BCT Thread

I am not affiliated with Ripple Labs.
User avatar
twarden
 
Posts: 737
Joined: Fri Jul 04, 2014 11:21 pm
Location: Ontario, Canada

Re: tecPATH_DRY - Take a look at my JSON object

Postby virajkamat » Tue Mar 22, 2016 6:53 am

How do I access the delivered_amount field. It isn't present in the transaction details retrieved using the transaction_id (hash).

I have also set the allowPartialPayment flag to true though it gives me a tec_PATHDRY error.

Whats confusing is a ripple Desktop client I came across works fine giving me a good exchange rate, and using the code I've written the transaction gives me a 2.5 USD/EUR exchange rate for the same amount. I've tried setting the limitQuality and also tried the path_find method to find and use the best path but the issue of tecPATH_DRY persists.
virajkamat
 
Posts: 19
Joined: Wed Mar 09, 2016 8:29 am

Re: tecPATH_DRY - Take a look at my JSON object

Postby twarden » Tue Mar 22, 2016 3:17 pm

virajkamat wrote:How do I access the delivered_amount field. It isn't present in the transaction details retrieved using the transaction_id (hash).

I have also set the allowPartialPayment flag to true though it gives me a tec_PATHDRY error.

Whats confusing is a ripple Desktop client I came across works fine giving me a good exchange rate, and using the code I've written the transaction gives me a 2.5 USD/EUR exchange rate for the same amount. I've tried setting the limitQuality and also tried the path_find method to find and use the best path but the issue of tecPATH_DRY persists.


My apologies, delivered_amount is not available for partial payments.

The issue you are experiencing with tecPATH_DRY either means you cannot access liquidity or the source and destination accounts have an insufficent trust limit. Have you checked that the trust-lines between the source and destination account are sufficient? Once you know if the accounts' trust-lines are set, try to include the DeliverMin field in your payment object an set its value to something conservative like 1-5% less than your maxAmountSend variable.
XAGATE Thread~QGK

Robbieboy2 wrote:I think datz is the right man to answer this.
pigeons wrote:That's exactly what I was thinking as I read this!


Don't worry! I'm pretty sure that I got this under control, the last crazy visionary was was far too insane, but I struck the correct balance.
BCT Thread

I am not affiliated with Ripple Labs.
User avatar
twarden
 
Posts: 737
Joined: Fri Jul 04, 2014 11:21 pm
Location: Ontario, Canada

Re: tecPATH_DRY - Take a look at my JSON object

Postby JoelKatz » Tue Mar 22, 2016 9:42 pm

Are you sending funds to yourself? It's very unusual for the source and destination assets to have the same counterparty. Usually the source counterparty is the sender and the destination amount counterparty is the recipient.
User avatar
JoelKatz
Ripple
Ripple
 
Posts: 1859
Joined: Sun Dec 23, 2012 3:45 pm
Location: Oakland, CA

Re: tecPATH_DRY - Take a look at my JSON object

Postby virajkamat » Wed Mar 23, 2016 3:29 pm

JoelKatz wrote:Are you sending funds to yourself? It's very unusual for the source and destination assets to have the same counterparty. Usually the source counterparty is the sender and the destination amount counterparty is the recipient.


I'm trying to send the funds between two different accounts. The address was stored in a variable named address. I tried using the getPaths function as well, though the error recurred. I'm not sure why it manages to go through with a windows app I'm using for the same.
virajkamat
 
Posts: 19
Joined: Wed Mar 09, 2016 8:29 am

Re: tecPATH_DRY - Take a look at my JSON object

Postby JoelKatz » Wed Mar 23, 2016 5:09 pm

If you don't particularly care what assets are used to make the payment, the issuers for the source and destination amounts should be the source and destination accounts respectively.
User avatar
JoelKatz
Ripple
Ripple
 
Posts: 1859
Joined: Sun Dec 23, 2012 3:45 pm
Location: Oakland, CA

Re: tecPATH_DRY - Take a look at my JSON object

Postby virajkamat » Fri Mar 25, 2016 5:00 am

JoelKatz wrote:If you don't particularly care what assets are used to make the payment, the issuers for the source and destination amounts should be the source and destination accounts respectively.


Thanks man !! It's working, you're a GOD :+1: :+1: :+1:

Can you please explain the concept to me, I mean we did register with a particular gateway and used the same to buy our respective assets; USD for sender and EUR for the receiver, though we're mentioning their account addresses as the respective counterparty when sending and receiving funds.
virajkamat
 
Posts: 19
Joined: Wed Mar 09, 2016 8:29 am

Re: tecPATH_DRY - Take a look at my JSON object

Postby JoelKatz » Sat Mar 26, 2016 7:12 pm

Pathfinding exists to find paths. If you know the paths, don't use pathfinding.

Well, you actually can use pathfinding in cases where you constrain or specify the paths. In that case, pathfinding can find the missing portions of the path or it can figure out whether the payment is possible or what the rate will be. But these uses are more complex.

In the simplest case, you let pathfinding find the paths. Then you don't have to deal with the intricacies of how you specify constraints and of you copy those constraints into the payment.

The issuer on a line from Alice to Bob is either Alice or Bob, depending on the direction the asset is flowing and whether you think of the thing flowing as an asset or an obligation. Ripple doesn't compel you take this into account when specifying the issuer. On a line from Alice to Bob, the "issuer" can equally be considered Alice or Bob. So when you specify Alice as the issuer of the source of a payment from Alice, that includes all of Alice's trust lines. When you specify Bob as the issuer of the destination of a payment to Bob, that includes all of Bob's trust lines. That lets pathfinding do its job.
User avatar
JoelKatz
Ripple
Ripple
 
Posts: 1859
Joined: Sun Dec 23, 2012 3:45 pm
Location: Oakland, CA


Return to Developers

Who is online

Users browsing this forum: No registered users and 2 guests