Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Paul/saved action #574

Merged
merged 8 commits into from
Jan 4, 2024
Merged

Paul/saved action #574

merged 8 commits into from
Jan 4, 2024

Conversation

paullinator
Copy link
Member

@paullinator paullinator commented Nov 30, 2023

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

  • Yes
  • No

Dependencies

none

Description

none

src/core/currency/wallet/currency-wallet-api.ts Outdated Show resolved Hide resolved
src/core/currency/wallet/currency-wallet-api.ts Outdated Show resolved Hide resolved

nativeAmount: { [currencyCode: string]: string }
networkFee: { [currencyCode: string]: string }
tokenId: string | null
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There cannot be a tokenId inside a MergedTransaction, because this combines all the coins together.

I see that there is a currencyCode in there already. This was a mistake from Eliran, and we should delete it.

The only place where we use the tokenId / currencyCode is in the onBlockHeightChanged processor. Since the goal is to update the block height, we either need to iterate over Object.keys(MergedTransaction.tokens) to update every currency, or since that will cost a lot of bridge traffic, we could just use the default currency code / null tokenId, but fix the GUI to handle block-height changes in a currency-agnostic way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. Agreed. But such a change is a bit outside the scope of this PR. Can we punt that to another task. The tokenId here at least mirrors the currencyCode use and they can both be fixed simultaneously when we agree on the method.

Comment on lines 210 to 218
export const asNumeralString = (raw: any): string => {
if (typeof raw !== 'string') throw new Error('Not type string')
if (isNaN(Number(raw))) throw new Error('Does not parse as a number')
return raw
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have asIntegerString. Please use that.

Otherwise, if you want decimal support, we should make an asDecimalString using a regexp. Remember, biggystring doesn't support 1E+6 syntax, but JavaScript does, so we need to be more picky than just using isNaN(Number(raw)). Inputs could pass this filter that still crash the app.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intent was decimal support although unneeded for its current use. Once Sam merges his biggystring PR we'll have full scientific notation support. For now I'll change to asIntegerString

Copy link
Contributor

@swansontec swansontec Dec 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I think this is the right solution in any case, since these are native amounts. Native amounts should never have decimal points or exponents.

src/core/currency/wallet/currency-wallet-api.ts Outdated Show resolved Hide resolved
src/core/currency/wallet/currency-wallet-api.ts Outdated Show resolved Hide resolved
test/core/currency/wallet/currency-wallet.test.ts Outdated Show resolved Hide resolved
src/core/currency/wallet/currency-wallet-cleaners.ts Outdated Show resolved Hide resolved
export const asEdgeTxActionFiatType: Cleaner<EdgeTxActionFiatType> = asValue(
'buy',
'sell',
'sellNetworkFee'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, so with this design, we need to save two copies of the action, duplicating the orderId and all other fields. One copy goes with the parent currency as a fee, and one goes with the token. The only difference between the two copies is the type field.

You already have a tokenId inside the action itself, so there is no need for this duplication. The GUI can easily see which side is the fee and which side is the sell by using tx.tokenId === savedAction.cryptoAsset.tokenId.

So, I really think the whole concept of saving the action per-currency is a mistake. There should be one action per transaction, saved at the root level.

When we first discussed this, I trusted your assertion that the actions needed to be saved per-token. Now that I'm seeing what the action looks like, I think that's a deeply flawed assumption.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the case of a fiat transaction this might be simple, but consider a DEX swap on Ripple. You have an action to create an order which pays XRP, the outgoing send which is considered a 'swap' which could pay USD.bs, then the receive which is the fulfillment that receives USD.gh. Do you really want the GUI to have to figure that all out.

As well the plugins report transactions per asset as they send individual EdgeTransactions. Now while they might not use savedAction but instead action, they would still be putting the action info per asset which we don't want to conflict.

@paullinator paullinator force-pushed the paul/savedAction branch 7 times, most recently from d25d4f7 to 1cb4bba Compare December 6, 2023 23:57
Copy link
Contributor

@swansontec swansontec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some changes on the metadata stuff.

I don't really understand the new savedAction / chainAction / assetAction design. I see that savedAction / assetAction are per-transaction, which makes sense, and the new assetAction is per asset. What I don't understand is how the plugin / app coordinate on setting up assetAction.

Comment on lines 72 to 73
export const PARENT_TOKEN_ID = ''

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this line should live in currency-wallet-files.ts, since it's related to the on-disk representation.

Comment on lines 36 to 48
category?: string | null
exchangeAmount: { [fiatCurrencyCode: string]: number }
name?: string
notes?: string
name?: string | null
notes?: string | null
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't actually want to store null on disk. The only reason we allow null in the user-facing type is to be able to delete fields. We need to revert this type definition, plus whatever changes are needed to the merging / updating code to make that work.

If could make sense to defined an EdgeMetadataChange type that includes | null for the fields that can be deleted, and revert the original EdgeMetadata type to how it was before. That makes it clear that metadata will never contain nulls. It's just a sigil for deleting fields.

Comment on lines 207 to 228
category: asNullable(asString),
exchangeAmount: asOptional(asObject(asNumber), () => ({})),
name: asOptional(asString),
notes: asOptional(asString)
name: asNullable(asString),
notes: asNullable(asString)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here. We don't want to save null on disk.

@paullinator paullinator force-pushed the paul/savedAction branch 2 times, most recently from d1a4196 to fe7e855 Compare December 19, 2023 05:15
@paullinator
Copy link
Member Author

Just some changes on the metadata stuff.

I don't really understand the new savedAction / chainAction / assetAction design. I see that savedAction / assetAction are per-transaction, which makes sense, and the new assetAction is per asset. What I don't understand is how the plugin / app coordinate on setting up assetAction.

This works as follows. Plugins edit chainAction which is per tx and chainAssetAction which is per asset per tx

GUI edits savedAction which is per tx and assetAction which is per asset per tx. All four are needed unfortunately because of separation of chain vs gui and per asset vs per tx.

@paullinator paullinator enabled auto-merge January 4, 2024 19:59
@paullinator paullinator merged commit 1127c3c into master Jan 4, 2024
3 checks passed
@paullinator paullinator deleted the paul/savedAction branch January 4, 2024 20:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants