Error Logs
Error Logs

Error Logs

Error Logs

icon
Error Log [Alpha] provides developers visibility into purchased transactions that were failed by the Dapper Platform. Detailed errors are logged in the Developer Portal under each Application’s page. It allows developers to look up recent and previous errors with timestamp, trace id, error details and the failure types. Please refer to the Error Code & Resolution section below for more details.

Usage

To reach the Error Log page, navigate to the desire application page in the Developer portal and click on View error log

image

Each error entry contains the following fields

Name:
Description:
Time
Timestamp of error in local time.
Error Code
The classification of error.
Trace ID
The trace identifier of the error.
Details
A high-level description of the error.
Data Details
Additional metadata of the transaction, ie. arguments, type, id, etc.

image

image

Error Codes & Resolutions

Error Code
Description
TXI-301
Missing seller address
TXI-302
First argument not of the address type
TXI-303
Seller address not of the Dapper Platform
TXI-901
Failed execution of metadata script
TXI-902
Incorrect return type of metadata script

TXI-301 - Missing merchant address

On Dapper Platform, it is mandatory for the Address of the seller to be the first argument for the transaction. Chances are it’s not being sent through FCL.

Resolution:

Append the address as an argument to the FCL mutation call:

await fcl.mutate({
	...
  args: (arg, t) => [
	  arg("0xcd7e0dfeb71e1e8a", t.Address) // This MUST be here
		... // other args for the Transaction
	],
})

TXI-302 - First argument not of the address type

As mentioned in TX-301, the first argument of the transaction must be of the type, Address.

Resolution:

Make sure your first argument is of type Address and check if its value is a well-formatted Flow Address, starting with 0x.

arg("0xcd7e0dfeb71e1e8a", t.Address) // It must have the `0x` prefix.

TXI-303 - Seller address not of the Dapper Platform

Only Dapper accounts can be used as the seller. This error occurs when a non-Dapper account was passed-in.

Resolution:

Depending on whether the purchase transaction is primary (direct) or secondary (P2P), different values are to be used.

Transaction Type
Required Address
Primary Sales
The merchant/organization address assigned to you by Dapper. Can be fund in the Payout & report section of the developer portal as indicated below.
Secondary Sales
The Dapper account address of the seller.
image

TXI-901 - Failed execution of metadata script

Something went wrong while executing the associated metadata script. Cadence error details are located in the Details column of each error entry.

Resolution:

Observe any clues in the Details section. Common mistakes include:

  • The metadata script arguments mis-matches against the corresponding FCL request. The number, type and order of arguments must be preserved.
  • Metadata script ran into an execution error. The error message is captured in the error log entry and indicate reason.

TXI-902 - Incorrect return type of metadata script

The metadata script did not return the expected well-formed PurchaseData structure.

Resolution:

Make sure following Purchase Data structure is returned:

pub struct PurchaseData {
  pub let id: UInt64
  pub let name: String
  pub let amount: UFix64
  pub let description: String
  pub let imageURL: String
  pub let paymentVaultTypeID: Type
}

The signature of the metadata script should resemble the following:

pub fun main(sellerAddress: Address, price: UFix64, id: UInt64): PurchaseData

Example:

Keep in mind the arguments of the script must match the ones sent through FCL during transaction invocation. For the above script as an example, the corresponding transaction signature is required to be:

transaction(sellerAddress: Address, price: UFix64, id: UInt64)

And the corresponding FCL mutate call:

await fcl.mutate({
	...
  args: (arg, t) => [
	  arg("0xcd7e0dfeb71e1e8a", t.Address),
    arg("9.99", t.UFix64),
    arg(73532, t.UInt64)
	],
})

FAQ

❓
Why doesn’t a non-whitelisted transaction showing up in Error Log?

The Dapper platform is not able to tie a non-whitelisted transaction to an Dapp nor an Organization. The error message that you would see through FCL is, This transaction is not supported.

❓
What are the places where errors can happen?

Errors can happen at the application level, Dapper Platform as well as on the blockchain. Errors that originate from the application can be observed in the application log. Errors that originate on the Dapper Platform is surfaced in the Error Log. Errors that happen on the blockchain can be observed through the Flowscan tool.

❓
Does the error log show all the errors?

Error log only show the errors that originates from Dapper platform as we inspect the transaction.

❓
Would I see errors being surfaced as they occur?

At this time, you must refresh the page in order to see the latest errors.

👋
Next: Back Home →