Remit does not call the token issuer's Hook as weakTSH. (Version: 2024.3.12-release+790 )

[tequdev]

Issue Description

If a token is specified in the Amounts field of a Remit transaction, the Hook of that token issuer will not be invoked.

Expected Result

The issuer of the token being sent must be weakTSH.

Actual Result

The issuer of the token being sent is not TSH.

Environment

xahaud 2024.3.12-release+790

Supporting Files

https://gist.github.com/tequdev/dd19dfaacca7bd3372b646f423004a03

[RichardAH]

good catch, an oversight indeed

will fix it on the next binary

[dangell7]

If we add this to Remit then we need to decide if we should add this to payment as well. Related to #262

[tequdev]

I guess Payment and OfferCreate transactions set the weakTSH through addWeakTSHFromSandbox().

xahaud/src/ripple/app/tx/impl/Transactor.cpp

Line 1448 in d24c134

Transactor::addWeakTSHFromSandbox(detail::ApplyViewBase const& pv)

[tequdev]

We need to support this in transactors (Escrow, Paychan, Check) that do not use PaymentSandbox.

[tequdev]

I guess Payment and OfferCreate transactions set the weakTSH through addWeakTSHFromSandbox().

xahaud/src/ripple/app/tx/impl/Transactor.cpp

Line 1448 in d24c134

Transactor::addWeakTSHFromSandbox(detail::ApplyViewBase const& pv)

Ah, this is for non-issuer.

[dangell7]

addWeakTSHFromSandbox executes on crossed account that are not the issuer. So I think this is a different issue? Also does Escrow, Paychan and Check use pathing?

[tequdev]

Yes, the result would be the same as the existing issue.
Is this a issue that needs to be fixed? Or is this a feature that is expected to be added in the future?

It may affect the validator's vote.

[dangell7]

Technically its a feature imo but if @RichardAH is open to it we could add it.

[RichardAH]

I think issuers should be weak tshes on all dealing in their currencies. It's over-looked in a bunch of places indeed.

[tequdev]

When is it appropriate to handle the issuer as a weakTSH?

A. when the IOU actually moves (eg. CheckCash)
B. when an IOU is specified in the transaction field (eg. CheckCreate)
C. when an Account field containing IOUs exists in the leisure object and they have changed (eg. CheckCancel)

The strictest will be A only and the loosest will be A+B+C.

The choices would be A or A+B or A+B+C