[bug]: `transactionType` value in the `QueryAssetRatesRequest` is not defined

[jcbrand]

Background

When creating an asset invoice, the transactionType value in the QueryAssetRatesRequest is not defined.
Instead, it should be set to zero. I suspect there might be a bug where it's not included because its value is not truthy.

Your environment

litd@bob:/$ tapcli getinfo
{
    "version": "0.7.0-alpha.rc2 commit=v0.7.0-rc2",
    "lnd_version": "0.20.0-beta.rc2",
    "network": "regtest",
    "lnd_identity_pubkey": "035586174e8f629f30a3055179c95c2dd689155ca22f7dde0d65de182bd4c992dc",
    "node_alias": "bob",
    "block_height": 150,
    "block_hash": "149c391c0a32baa01a4d8be7bd69af4af11b8d6e4a90d5ec87eceae7ef7ab799",
    "sync_to_chain": false
}

litd@bob:/$ uname -mrsv   
Linux 6.8.0-90-generic #91-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 18 14:14:30 UTC 2025 x86_64

Steps to reproduce

Create an invoice for which you want to be paid in a Taproot Asset.

Inside the Price Oracle, where QueryAssetRates is called, inspect the request object and notice that transactionType is not included in the request.

Expected behavior

The value should be zero (for an asset SALE PURCHASE).

Actual behavior

No value is set.

[Roasbeef]

Instead, it should be set to zero. I suspect there might be a bug where it's not included because its value is not truthy.

taproot-assets/taprpc/priceoraclerpc/price_oracle.proto

Lines 164 to 166 in daf5060

	// transaction_type indicates whether the transaction is a purchase or a
	// sale.
	TransactionType transaction_type = 1;

taproot-assets/taprpc/priceoraclerpc/price_oracle.proto

Lines 17 to 24 in daf5060

	// TransactionType is an enum representing the type of transaction.
	enum TransactionType {
	// PURCHASE indicates a purchase transaction.
	PURCHASE = 0;
	// SALE indicates a sale transaction.
	SALE = 1;
	}

The value should be zero (for an asset SALE).

Based on the links above, you'd expect it to be 1 for an asset sale. Can you provide further examples here? IIUC the zero value is the default, so if noting specifies it, then it won't be serialized, but the proto client should detect that it's the zero value.

[jcbrand]

Based on the links above, you'd expect it to be 1 for an asset sale

Sorry, I meant PURCHASE then and not SALE. 🙈

IIUC the zero value is the default, so if noting specifies it, then it won't be serialized, but the proto client should detect that it's the zero value.

Looks like you're right and that showing undefined is behavior from protobuf.js.

Sorry for the noise!

[jcbrand]

@Roasbeef I still think there might be an issue here, unless I don't properly understand the difference between SALE and PURCHASE.

My understanding is that whether its a SALE or a PURCHASE is from the perspective of the edge node and regarding the asset.

So if I want to pay an invoice with an asset, I want the edge node to buy the asset from me, and so it's a PURCHASE, right?

Ok, so here's what I did:

• I created a BTC invoice.
• Then I tried to pay that invoice with an asset.

My Price Oracle gets called twice.

First with this data:

[Nest] 63  - 01/07/2026, 9:27:38 AM   DEBUG [PriceOracleService] queryAssetRates called
[Nest] 63  - 01/07/2026, 9:27:38 AM   DEBUG [PriceOracleService] Object(6) {
  subjectAsset: {
    assetId: <Buffer f8 6a 8b 12 4b 8b d5 00 97 54 87 96 c1 df 68 14 10 c2 c1 4e fb 63 71 d3 05 9d b0 df 66 11 2e 45>
  },
  paymentAsset: {
    assetId: <Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>
  },
  paymentAssetMaxAmount: Long {
    low: 200000,
    high: 0,
    unsigned: true
  },
  intent: 2,
  counterpartyId: <Buffer 03 55 86 17 4e 8f 62 9f 30 a3 05 51 79 c9 5c 2d d6 89 15 5c a2 2f 7d de 0d 65 de 18 2b d4 c9 92 dc>,
  metadata: '{\n  "swapNodePubkey": "0266da2cb2fc030eb66639d276304fde7ada446bba2ddbe55f88d1cb5819fe4697"\n}'
}

So based on the intent value of 2 the intent is INTENT_PAY_INVOICE which makes sense.

Note, that there is no transactionType value. Given that this is a PURCHASE, the value should be 1, right?

Then, afterwards, my PO gets called again, with this data:

[Nest] 63  - 01/07/2026, 9:27:39 AM   DEBUG [PriceOracleService] queryAssetRates called
[Nest] 63  - 01/07/2026, 9:27:39 AM   DEBUG [PriceOracleService] Object(8) {
  transactionType: 1,
  subjectAsset: {
    assetId: <Buffer f8 6a 8b 12 4b 8b d5 00 97 54 87 96 c1 df 68 14 10 c2 c1 4e fb 63 71 d3 05 9d b0 df 66 11 2e 45>
  },
  paymentAsset: {
    assetId: <Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>
  },
  paymentAssetMaxAmount: Long {
    low: 200000,
    high: 0,
    unsigned: true
  },
  assetRatesHint: {
    subjectAssetRate: {
      coefficient: '91812043076'
    },
    paymentAssetRate: {
      coefficient: '100000000000',
      scale: 9
    },
    expiryTimestamp: Long {
      low: 1767778119,
      high: 0,
      unsigned: true
    }
  },
  intent: 3,
  counterpartyId: <Buffer 02 66 da 2c b2 fc 03 0e b6 66 39 d2 76 30 4f de 7a da 44 6b ba 2d db e5 5f 88 d1 cb 58 19 fe 46 97>,
  metadata: '{\n  "swapNodePubkey": "0266da2cb2fc030eb66639d276304fde7ada446bba2ddbe55f88d1cb5819fe4697"\n}'
}

This time we have an intent of 3 which is INTENT_PAY_INVOICE_QUALIFY which also makes sense. The node is doing a sanity check on the value it received previously.

Note that this time we have transactionType: 1

Shouldn't I also be receiving a transactionType of 1 in the first call?

[jtobin]

Whoops, I managed to accidentally close this one. Reopened.