2019-10-11 16:51:14 +01:00
|
|
|
// Copyright (C) 2019 Storj Labs, Inc.
|
|
|
|
// See LICENSE for copying information.
|
|
|
|
|
|
|
|
package coinpayments
|
|
|
|
|
|
|
|
import (
|
|
|
|
"context"
|
|
|
|
"encoding/json"
|
|
|
|
"net/url"
|
|
|
|
"strconv"
|
|
|
|
"strings"
|
|
|
|
"time"
|
|
|
|
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
"github.com/shopspring/decimal"
|
2019-10-11 16:51:14 +01:00
|
|
|
"github.com/zeebo/errs"
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
|
|
|
|
"storj.io/storj/satellite/payments/monetary"
|
2019-10-11 16:51:14 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
const (
|
|
|
|
cmdCreateTransaction = "create_transaction"
|
|
|
|
cmdGetTransactionInfo = "get_tx_info"
|
|
|
|
cmdGetTransactionInfoList = "get_tx_info_multi"
|
|
|
|
)
|
|
|
|
|
|
|
|
// Status is a type wrapper for transaction statuses.
|
|
|
|
type Status int
|
|
|
|
|
|
|
|
const (
|
|
|
|
// StatusCancelled defines cancelled or timeout transaction.
|
|
|
|
StatusCancelled Status = -1
|
|
|
|
// StatusPending defines pending transaction which is waiting for buyer funds.
|
|
|
|
StatusPending Status = 0
|
|
|
|
// StatusReceived defines transaction which successfully received required amount of funds.
|
|
|
|
StatusReceived Status = 1
|
2020-01-14 13:38:32 +00:00
|
|
|
// StatusCompleted defines transaction which is fully completed.
|
|
|
|
StatusCompleted Status = 100
|
2019-10-11 16:51:14 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
// Int returns int representation of status.
|
|
|
|
func (s Status) Int() int {
|
|
|
|
return int(s)
|
|
|
|
}
|
|
|
|
|
|
|
|
// String returns string representation of status.
|
|
|
|
func (s Status) String() string {
|
|
|
|
switch s {
|
|
|
|
case StatusCancelled:
|
|
|
|
return "cancelled/timeout"
|
|
|
|
case StatusPending:
|
|
|
|
return "pending"
|
|
|
|
case StatusReceived:
|
|
|
|
return "received"
|
2020-01-14 13:38:32 +00:00
|
|
|
case StatusCompleted:
|
|
|
|
return "completed"
|
2019-10-11 16:51:14 +01:00
|
|
|
default:
|
|
|
|
return "unknown"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// TransactionID is type wrapper for transaction id.
|
|
|
|
type TransactionID string
|
|
|
|
|
|
|
|
// String returns string representation of transaction id.
|
|
|
|
func (id TransactionID) String() string {
|
|
|
|
return string(id)
|
|
|
|
}
|
|
|
|
|
|
|
|
// TransactionIDList is a type wrapper for list of transactions.
|
|
|
|
type TransactionIDList []TransactionID
|
|
|
|
|
|
|
|
// Encode returns encoded string representation of transaction id list.
|
|
|
|
func (list TransactionIDList) Encode() string {
|
|
|
|
if len(list) == 0 {
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
if len(list) == 1 {
|
|
|
|
return string(list[0])
|
|
|
|
}
|
|
|
|
|
|
|
|
var builder strings.Builder
|
|
|
|
for _, id := range list[:len(list)-1] {
|
|
|
|
builder.WriteString(string(id))
|
|
|
|
builder.WriteString("|")
|
|
|
|
}
|
|
|
|
|
|
|
|
builder.WriteString(string(list[len(list)-1]))
|
|
|
|
return builder.String()
|
|
|
|
}
|
|
|
|
|
|
|
|
// Transaction contains data returned on transaction creation.
|
|
|
|
type Transaction struct {
|
|
|
|
ID TransactionID
|
|
|
|
Address string
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
Amount monetary.Amount
|
2019-10-11 16:51:14 +01:00
|
|
|
DestTag string
|
|
|
|
ConfirmsNeeded int
|
|
|
|
Timeout time.Duration
|
|
|
|
CheckoutURL string
|
|
|
|
StatusURL string
|
|
|
|
QRCodeURL string
|
|
|
|
}
|
|
|
|
|
|
|
|
// UnmarshalJSON handles json unmarshaling for transaction.
|
|
|
|
func (tx *Transaction) UnmarshalJSON(b []byte) error {
|
|
|
|
var txRaw struct {
|
|
|
|
Amount string `json:"amount"`
|
|
|
|
Address string `json:"address"`
|
|
|
|
DestTag string `json:"dest_tag"`
|
|
|
|
TxID string `json:"txn_id"`
|
|
|
|
ConfirmsNeeded string `json:"confirms_needed"`
|
|
|
|
Timeout int `json:"timeout"`
|
|
|
|
CheckoutURL string `json:"checkout_url"`
|
|
|
|
StatusURL string `json:"status_url"`
|
|
|
|
QRCodeURL string `json:"qrcode_url"`
|
|
|
|
}
|
|
|
|
|
|
|
|
if err := json.Unmarshal(b, &txRaw); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
amount, err := monetary.AmountFromString(txRaw.Amount, monetary.StorjToken)
|
2019-10-11 16:51:14 +01:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
confirms, err := strconv.ParseInt(txRaw.ConfirmsNeeded, 10, 64)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
*tx = Transaction{
|
|
|
|
ID: TransactionID(txRaw.TxID),
|
|
|
|
Address: txRaw.Address,
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
Amount: amount,
|
2019-10-11 16:51:14 +01:00
|
|
|
DestTag: txRaw.DestTag,
|
|
|
|
ConfirmsNeeded: int(confirms),
|
|
|
|
Timeout: time.Second * time.Duration(txRaw.Timeout),
|
|
|
|
CheckoutURL: txRaw.CheckoutURL,
|
|
|
|
StatusURL: txRaw.StatusURL,
|
|
|
|
QRCodeURL: txRaw.QRCodeURL,
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// TransactionInfo holds transaction information.
|
|
|
|
type TransactionInfo struct {
|
|
|
|
Address string
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
Coin CurrencySymbol
|
|
|
|
Amount decimal.Decimal
|
|
|
|
Received decimal.Decimal
|
2019-10-11 16:51:14 +01:00
|
|
|
ConfirmsReceived int
|
|
|
|
Status Status
|
|
|
|
ExpiresAt time.Time
|
|
|
|
CreatedAt time.Time
|
|
|
|
}
|
|
|
|
|
|
|
|
// UnmarshalJSON handles json unmarshaling for transaction info.
|
|
|
|
func (info *TransactionInfo) UnmarshalJSON(b []byte) error {
|
|
|
|
var txInfoRaw struct {
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
Address string `json:"payment_address"`
|
|
|
|
Coin string `json:"coin"`
|
|
|
|
Status int `json:"status"`
|
|
|
|
Amount decimal.Decimal `json:"amountf"`
|
|
|
|
Received decimal.Decimal `json:"receivedf"`
|
|
|
|
ConfirmsRecv int `json:"recv_confirms"`
|
|
|
|
ExpiresAt int64 `json:"time_expires"`
|
|
|
|
CreatedAt int64 `json:"time_created"`
|
2019-10-11 16:51:14 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if err := json.Unmarshal(b, &txInfoRaw); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
*info = TransactionInfo{
|
|
|
|
Address: txInfoRaw.Address,
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
Coin: CurrencySymbol(txInfoRaw.Coin),
|
|
|
|
Amount: txInfoRaw.Amount,
|
|
|
|
Received: txInfoRaw.Received,
|
2019-10-11 16:51:14 +01:00
|
|
|
ConfirmsReceived: txInfoRaw.ConfirmsRecv,
|
|
|
|
Status: Status(txInfoRaw.Status),
|
|
|
|
ExpiresAt: time.Unix(txInfoRaw.ExpiresAt, 0),
|
|
|
|
CreatedAt: time.Unix(txInfoRaw.CreatedAt, 0),
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// TransactionInfos is map of transaction infos by transaction id.
|
|
|
|
type TransactionInfos map[TransactionID]TransactionInfo
|
|
|
|
|
|
|
|
// UnmarshalJSON handles json unmarshaling for TransactionInfos.
|
|
|
|
func (infos *TransactionInfos) UnmarshalJSON(b []byte) error {
|
|
|
|
var _infos map[TransactionID]TransactionInfo
|
|
|
|
|
|
|
|
var errors map[TransactionID]struct {
|
|
|
|
Error string `json:"error"`
|
|
|
|
}
|
|
|
|
|
|
|
|
if err := json.Unmarshal(b, &errors); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
var errg errs.Group
|
|
|
|
for _, info := range errors {
|
|
|
|
if info.Error != "ok" {
|
|
|
|
errg.Add(errs.New(info.Error))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if err := errg.Err(); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
if err := json.Unmarshal(b, &_infos); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
for id, info := range _infos {
|
|
|
|
(*infos)[id] = info
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// CreateTX defines parameters for transaction creating.
|
|
|
|
type CreateTX struct {
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
Amount decimal.Decimal
|
|
|
|
CurrencyIn *monetary.Currency
|
|
|
|
CurrencyOut *monetary.Currency
|
2019-10-11 16:51:14 +01:00
|
|
|
BuyerEmail string
|
|
|
|
}
|
|
|
|
|
|
|
|
// Transactions defines transaction related API methods.
|
|
|
|
type Transactions struct {
|
|
|
|
client *Client
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create creates new transaction.
|
2019-11-12 11:14:34 +00:00
|
|
|
func (t Transactions) Create(ctx context.Context, params *CreateTX) (*Transaction, error) {
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
cpSymbolIn, ok := currencySymbols[params.CurrencyIn]
|
|
|
|
if !ok {
|
|
|
|
return nil, Error.New("can't identify coinpayments currency symbol for %q", params.CurrencyIn.Name())
|
|
|
|
}
|
|
|
|
cpSymbolOut, ok := currencySymbols[params.CurrencyOut]
|
|
|
|
if !ok {
|
|
|
|
return nil, Error.New("can't identify coinpayments currency symbol for %q", params.CurrencyOut.Name())
|
|
|
|
}
|
2019-10-11 16:51:14 +01:00
|
|
|
values := make(url.Values)
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
values.Set("amount", params.Amount.String())
|
|
|
|
values.Set("currency1", string(cpSymbolIn))
|
|
|
|
values.Set("currency2", string(cpSymbolOut))
|
2019-10-11 16:51:14 +01:00
|
|
|
values.Set("buyer_email", params.BuyerEmail)
|
|
|
|
|
|
|
|
tx := new(Transaction)
|
|
|
|
|
|
|
|
res, err := t.client.do(ctx, cmdCreateTransaction, values)
|
|
|
|
if err != nil {
|
|
|
|
return nil, Error.Wrap(err)
|
|
|
|
}
|
|
|
|
|
|
|
|
if err = json.Unmarshal(res, tx); err != nil {
|
|
|
|
return nil, Error.Wrap(err)
|
|
|
|
}
|
|
|
|
|
|
|
|
return tx, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// Info receives transaction info by transaction id.
|
|
|
|
func (t Transactions) Info(ctx context.Context, id TransactionID) (*TransactionInfo, error) {
|
|
|
|
values := make(url.Values)
|
|
|
|
values.Set("txid", id.String())
|
|
|
|
|
|
|
|
txInfo := new(TransactionInfo)
|
|
|
|
|
|
|
|
res, err := t.client.do(ctx, cmdGetTransactionInfo, values)
|
|
|
|
if err != nil {
|
|
|
|
return nil, Error.Wrap(err)
|
|
|
|
}
|
|
|
|
|
|
|
|
if err = json.Unmarshal(res, txInfo); err != nil {
|
|
|
|
return nil, Error.Wrap(err)
|
|
|
|
}
|
|
|
|
|
|
|
|
return txInfo, nil
|
|
|
|
}
|
|
|
|
|
2020-06-25 22:16:39 +01:00
|
|
|
// ListInfos returns transaction infos.
|
2019-10-11 16:51:14 +01:00
|
|
|
func (t Transactions) ListInfos(ctx context.Context, ids TransactionIDList) (TransactionInfos, error) {
|
2020-06-25 22:16:39 +01:00
|
|
|
// The service supports a max batch size of 25 items
|
|
|
|
const batchSize = 25
|
|
|
|
var allErrors error
|
|
|
|
numIds := len(ids)
|
|
|
|
txInfos := make(TransactionInfos, numIds)
|
|
|
|
|
|
|
|
for i := 0; i < len(ids); i += batchSize {
|
|
|
|
j := i + batchSize
|
|
|
|
if j > numIds {
|
|
|
|
j = numIds
|
|
|
|
}
|
|
|
|
batchInfos := make(TransactionInfos, j-i)
|
|
|
|
values := make(url.Values, j-i)
|
|
|
|
values.Set("txid", ids[i:j].Encode())
|
|
|
|
res, err := t.client.do(ctx, cmdGetTransactionInfoList, values)
|
|
|
|
if err != nil {
|
|
|
|
allErrors = errs.Combine(allErrors, err)
|
|
|
|
}
|
|
|
|
if err = json.Unmarshal(res, &batchInfos); err != nil {
|
|
|
|
allErrors = errs.Combine(allErrors, err)
|
|
|
|
}
|
|
|
|
for k, v := range batchInfos {
|
|
|
|
txInfos[k] = v
|
|
|
|
}
|
2019-10-11 16:51:14 +01:00
|
|
|
}
|
2020-06-25 22:16:39 +01:00
|
|
|
return txInfos, allErrors
|
2019-10-11 16:51:14 +01:00
|
|
|
}
|