kinecosystem / agora Goto Github PK

When I use the test environment python3 submit_payment.py -s="SCZY2FCCFXYGJYKLESDNKGO4VIBZB5L6KKLWOOFM3LZ63BBVAUGFJCNV" -d="GDFHSDO54RFPCWGISQPFDA4K6SMKTLJM43CKNWJFQBE62QZULUHNTTHS"
It returns an error below:
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.INTERNAL
details = "failed to store invoice list"
debug_error_string = "{"created":"@1602239731.580594000","description":"Error received from peer ipv4:23.23.244.109:443","file":"src/core/lib/surface/call.cc","file_line":1055,"grpc_message":"failed to store invoice list","grpc_status":13}"

You get a timeout unless you set the KinVersion to 4 explicitly.

https://github.com/kinecosystem/agora/blob/master/client/client.go#L111

Hello,

We have a fairly serious issue where on occasion our users open the app and their balance displays as 0. On closer inspection, it's because a new Kin SPL token account has been created on their Solana wallet. This obviously then leads to mistrust of our app, because it looks like we've lost all their Kin! Some of our users have tens of millions of Kin stored there.

Firstly - what is causing this? Is it because once in a while Agora and the Solana cluster does a lookup, finds no token account for some reason, and then creates one? Is a migration being triggered, even though they have already migrated?

Edit: My preliminary findings are that 100% of users affected by this issue were migrated from Kin3. All "new accounts" created on Kin4 have been unaffected (but my query will take a while to run).

Secondly - what can we do to resolve this while you look in to it?

If you'd like to see an example, I could probably give you at least 100 accounts where this has happened. But for now, here are four:

https://explorer.solana.com/address/Fc5ixhwo5kzCtEdb5zqtkFJ1sz1bxxApYZPPZ1JvaRPh/tokens?display=detail
https://explorer.solana.com/address/BNgnoZs1gtrmhZ8maZv9dFRNW3TP3QsuG8ebfrH3DbR/tokens?display=detail
https://explorer.solana.com/address/Ef8fRckj39V6tczsvCwg24mG3VkQzTjPxm8r477XDMvM/tokens?display=detail
https://explorer.solana.com/address/3kLL1z1XQVmE7g4zLdG6gaeYh8yDVRtw2XPsmw5isvoA/tokens?display=detail

The issue occurs after using both Android and iOS sdks.

Please let me know if you need any more info.

Thanks!

When I usd the client example to submit a payment

./main -sender="SDGRUVW32QR56BXAY46Q322IUSEGUMSX26ID5ODAGS7FD73C5FPADJFB" -dest="GDVZH4GLGV5CVCSMAOSPWCY6S6P5ZODO3VHU24GHF75ARE6DBB337E4C"

it showed the error below :
2020/10/09 23:34:22 failed to submit transaction: rpc error: code = Internal desc = failed to store invoice list

When we create 2 sequential unique transactions with same sender/receiver/amount within a short amount of time, we get the following error back:

"The operation couldn't be completed. (KinBase.KinServiceV4.Errors error 2.)"

If we wait some amount of time between initiating transactions, the 2nd txn goes through properly, and gets a unique txn ID.

We believe the issue is caused by Agora considering the txns non-unique, and dedupes / hands back the txn ID of the 1st txn instead of making a new 2nd txn ID.

Our request is for the ios/android/etc SDKs to handle this detail internally with Agora, so we as the implementers do not have to care/worry about the deduping logic.

For reference: on our app, it's very easy for users to send Kin tips to each other, and we have a default of 10 Kin. So often times, users will send tips to each other, using the default amount, which then triggers this issue.

We had tried to work around it by attempting to use some part of "memo" or "invoice" fields, but feel that the SDKs should handle this internally, but there were various issues, and also feel from an ease-of-use perspective, the implementers should not have to worry about internal Agora deduping logic, in case it changes in the future.

The token account returned by the SDKs is changing sometimes.

token_accounts = client2.resolve_token_accounts(PublicKey.from_string(public_key_address))
token_account = token_accounts[0]
balance = client2.get_balance(token_account)

Most of the time, the correct account is returned, but on some edge cases, the zero balance account is returned.

When I try to create an account on the Testnet, it consequently gets rate limited, while I'm not making a large amount of requests.

Running the same methods on Mainnet works as expected. It also works as expected when using the Node or Go SDK.

A demo can be found here, make sure to open the developer tools to get the error message.

Let me know if you need more info.

Without any change on our backend servers which run this code in a container, this out-of-memory (OOM) exception on our alerting started happening on August 24, 2020 -- surpassing the 220 MB per container threshold, going up to almost 1 GB before being evicted:

• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

We've upgraded the kin-node SDK, but it didn't have any effect.

We believe this was triggered via some backend update on the Kin Agora side, which didn't play nicely with what we have installed. We have not been able to trace what is causing the memory leak.

On the monitoring graphs, the containers exhibit classic sawtooth memory usage, which indicates the container is increasing in memory past the 220 MB threshold we had set up to 1 GB per container, until the container gets evicted by the cluster manager, and then a new instance is created. Before Aug 24, 2020 we did not see this behavior, as we've had this monitoring/alerting 220 MB memory usage threshold policy in place since 2019.

here is the yarn.lock which we have for the container:

"@kinecosystem/agora-api@^0.25.0":
  version "0.25.0"
  resolved "https://registry.yarnpkg.com/@kinecosystem/agora-api/-/agora-api-0.25.0.tgz#ce7a47fe293d725528be54051e8918c5ca1df0af"
  integrity sha512-qHReSX8QG2CT7I3znZQzxDv3KFIK+Zb4aMftfU5shNB0GNiJLclEbthckSKTzSd/5UX+eP5zfgc6WhU1N/CcUw==
  dependencies:
    "@types/google-protobuf" "^3.7.2"
    google-protobuf "^4.0.0-rc.2"
    grpc "^1.24.3"

"@kinecosystem/kin-sdk-v2@^0.3.5":
  version "0.3.11"
  resolved "https://registry.yarnpkg.com/@kinecosystem/kin-sdk-v2/-/kin-sdk-v2-0.3.11.tgz#cd363ee62116706a7e5b7382a87bfe17eae9d321"
  integrity sha512-5+U3IQkbfOzJ/nkUGM9cBugi+UIcpPHgm7YjrugMUabKQBceadhQGBTwoXnNEa8ppyb1zO0HyGQfhWCsq23EVw==
  dependencies:
    "@grpc/grpc-js" "^1.1.2"
    "@kinecosystem/agora-api" "^0.25.0"
    "@solana/web3.js" "^0.86.3"
    "@types/bs58" "^4.0.1"
    "@types/express" "^4.17.7"
    "@types/google-protobuf" "^3.7.2"
    "@types/lru-cache" "^5.1.0"
    "@types/uuid" "^8.3.0"
    bignumber.js "^9.0.0"
    bs58 "^4.0.1"
    bytebuffer "^5.0.1"
    express "^4.17.1"
    google-protobuf "^4.0.0-rc.2"
    grpc "^1.24.3"
    hash.js "^1.1.7"
    lru-cache "^6.0.0"
    protobufjs "^6.10.1"
    stellar-base "3.0.3"
    tweetnacl "^1.0.3"
    uuid "^8.3.2"

With the migration to solana it's become more important to be able to track specific error codes in our application. The current api for SubmitPayment only returns a simple error.

SubmitPayment(ctx context.Context, payment Payment, opts ...SolanaOption) (txHash []byte, err error)

Returning an actual error enum so it can be tracked in prometheus would be very helpful. Currently there is no list of all possible errors returned so its kind of a best effort to track errors.

SubmitPayment should either return a tx hash object that has a base58 method or add a generic base58 method to utils.go. It was not obvious how to turn txHash into something that can be inspected on the blockchian.

SubmitPayment(ctx context.Context, payment Payment, opts ...SolanaOption) (txHash []byte, err error)