Module processing
Last updated
Was this helpful?
Last updated
Was this helpful?
Message processing module.
This module incorporates functions related to complex message processing scenarios.
– Starts monitoring for the processing results of the specified messages.
– Returns summary information about current state of the specified monitoring queue.
– Fetches next resolved results from the specified monitoring queue.
– Cancels all background activity and releases all allocated system resources for the specified monitoring queue.
– Sends specified messages to the blockchain.
– Sends message to the network
– Performs monitoring of the network for the result transaction of the external inbound message processing.
– Creates message, sends it to the network and monitors its processing.
– Notifies the application that the account's current shard block will be fetched from the network. This step is performed before the message sending so that sdk knows starting from which block it will search for the transaction.
Starts monitoring for the processing results of the specified messages.
Message monitor performs background monitoring for a message processing results for the specified set of messages.
Message monitor can serve several isolated monitoring queues. Each monitor queue has a unique application defined identifier (or name) used to separate several queue's.
There are two important lists inside of the monitoring queue:
unresolved messages: contains messages requested by the application for monitoring and not yet resolved;
resolved results: contains resolved processing results for monitored messages.
Each monitoring queue tracks own unresolved and resolved lists. Application can add more messages to the monitoring queue at any time.
Message monitor accumulates resolved results. Application should fetch this results with fetchNextMonitorResults
function.
When both unresolved and resolved lists becomes empty, monitor stops any background activity and frees all allocated internal memory.
If monitoring queue with specified name already exists then messages will be added to the unresolved list.
If monitoring queue with specified name does not exist then monitoring queue will be created with specified unresolved messages.
NOTE: Sync version is available only for lib-node
binding.
queue
: string – Name of the monitoring queue.
Returns summary information about current state of the specified monitoring queue.
NOTE: Sync version is available only for lib-node
binding.
queue
: string – Name of the monitoring queue.
unresolved
: number – Count of the unresolved messages.
resolved
: number – Count of resolved results.
Fetches next resolved results from the specified monitoring queue.
Results and waiting options are depends on the wait
parameter. All returned results will be removed from the queue's resolved list.
NOTE: Sync version is available only for lib-node
binding.
queue
: string – Name of the monitoring queue.
Cancels all background activity and releases all allocated system resources for the specified monitoring queue.
NOTE: Sync version is available only for lib-node
binding.
queue
: string – Name of the monitoring queue.
Sends specified messages to the blockchain.
NOTE: Sync version is available only for lib-node
binding.
monitor_queue
?: string – Optional message monitor queue that starts monitoring for the processing results for sent messages.
Sends message to the network
Sends message to the network and returns the last generated shard block of the destination account before the message was sent. It will be required later for message processing.
NOTE: Sync version is available only for lib-node
binding.
message
: string – Message BOC.
send_events
?: boolean – Flag for requesting events sending. Default is false
.
shard_block_id
: string – The last generated shard block of the message destination account before the message was sent.
This block id must be used as a parameter of the
wait_for_transaction
.
sending_endpoints
: string[] – The list of endpoints to which the message was sent.
This list id must be used as a parameter of the
wait_for_transaction
.
Performs monitoring of the network for the result transaction of the external inbound message processing.
send_events
enables intermediate events, such as WillFetchNextBlock
, FetchNextBlockFailed
that may be useful for logging of new shard blocks creation during message processing.
Note, that presence of the abi
parameter is critical for ABI compliant contracts. Message processing uses drastically different strategy for processing message for contracts which ABI includes "expire" header.
When the ABI header expire
is present, the processing uses message expiration
strategy:
The maximum block gen time is set to message_expiration_timeout + transaction_wait_timeout
.
When maximum block gen time is reached, the processing will be finished with MessageExpired
error.
When the ABI header expire
isn't present or abi
parameter isn't specified, the processing uses transaction waiting
strategy:
The maximum block gen time is set to now() + transaction_wait_timeout
.
If maximum block gen time is reached and no result transaction is found, the processing will exit with an error.
NOTE: Sync version is available only for lib-node
binding.
message
: string – Message BOC.
Encoded with base64
.
shard_block_id
: string – The last generated block id of the destination account shard before the message was sent.
You must provide the same value as the send_message
has returned.
send_events
?: boolean – Flag that enables/disables intermediate events. Default is false
.
sending_endpoints
?: string[] – The list of endpoints to which the message was sent.
Use this field to get more informative errors.
Provide the same value as the send_message
has returned.
If the message was not delivered (expired), SDK will log the endpoint URLs, used for its sending.
transaction
: any – Parsed transaction.
In addition to the regular transaction fields there is a
boc
field encoded with base64
which contains source
transaction BOC.
out_messages
: string[] – List of output messages' BOCs.
Encoded as base64
Creates message, sends it to the network and monitors its processing.
Creates ABI-compatible message, sends it to the network and monitors for the result transaction. Decodes the output messages' bodies.
If contract's ABI includes "expire" header, then SDK implements retries in case of unsuccessful message delivery within the expiration timeout: SDK recreates the message, sends it and processes it again.
The intermediate events, such as WillFetchFirstBlock
, WillSend
, DidSend
, WillFetchNextBlock
, etc - are switched on/off by send_events
flag and logged into the supplied callback function.
The retry configuration parameters are defined in the client's NetworkConfig
and AbiConfig
.
If contract's ABI does not include "expire" header then, if no transaction is found within the network timeout (see config parameter ), exits with error.
NOTE: Sync version is available only for lib-node
binding.
send_events
?: boolean – Flag for requesting events sending. Default is false
.
transaction
: any – Parsed transaction.
In addition to the regular transaction fields there is a
boc
field encoded with base64
which contains source
transaction BOC.
out_messages
: string[] – List of output messages' BOCs.
Encoded as base64
One of the following value:
MessageAlreadyExpired = 501
MessageHasNotDestinationAddress = 502
CanNotBuildMessageCell = 503
FetchBlockFailed = 504
SendMessageFailed = 505
InvalidMessageBoc = 506
MessageExpired = 507
TransactionWaitTimeout = 508
InvalidBlockReceived = 509
CanNotCheckBlockShard = 510
BlockNotFound = 511
InvalidData = 512
ExternalSignerMustNotBeUsed = 513
MessageRejected = 514
InvalidRempStatus = 515
NextRempStatusTimeout = 516
Notifies the application that the account's current shard block will be fetched from the network. This step is performed before the message sending so that sdk knows starting from which block it will search for the transaction.
Fetched block will be used later in waiting phase.
message_id
: string
message_dst
: string
Notifies the app that the client has failed to fetch the account's current shard block.
This may happen due to the network issues. Receiving this event means that message processing will not proceed - message was not sent, and Developer can try to run process_message
again, in the hope that the connection is restored.
message_id
: string
message_dst
: string
Notifies the app that the message will be sent to the network. This event means that the account's current shard block was successfully fetched and the message was successfully created (abi.encode_message
function was executed successfully).
shard_block_id
: string
message_id
: string
message_dst
: string
message
: string
Notifies the app that the message was sent to the network, i.e processing.send_message
was successfully executed. Now, the message is in the blockchain. If Application exits at this phase, Developer needs to proceed with processing after the application is restored with wait_for_transaction
function, passing shard_block_id and message from this event.
Do not forget to specify abi of your contract as well, it is crucial for processing. See processing.wait_for_transaction
documentation.
shard_block_id
: string
message_id
: string
message_dst
: string
message
: string
Notifies the app that the sending operation was failed with network error.
Nevertheless the processing will be continued at the waiting phase because the message possibly has been delivered to the node. If Application exits at this phase, Developer needs to proceed with processing after the application is restored with wait_for_transaction
function, passing shard_block_id and message from this event. Do not forget to specify abi of your contract as well, it is crucial for processing. See processing.wait_for_transaction
documentation.
shard_block_id
: string
message_id
: string
message_dst
: string
message
: string
Notifies the app that the next shard block will be fetched from the network.
Event can occurs more than one time due to block walking procedure. If Application exits at this phase, Developer needs to proceed with processing after the application is restored with wait_for_transaction
function, passing shard_block_id and message from this event. Do not forget to specify abi of your contract as well, it is crucial for processing. See processing.wait_for_transaction
documentation.
shard_block_id
: string
message_id
: string
message_dst
: string
message
: string
Notifies the app that the next block can't be fetched.
If no block was fetched within NetworkConfig.wait_for_timeout
then processing stops. This may happen when the shard stops, or there are other network issues. In this case Developer should resume message processing with wait_for_transaction
, passing shard_block_id, message and contract abi to it. Note that passing ABI is crucial, because it will influence the processing strategy.
Another way to tune this is to specify long timeout in NetworkConfig.wait_for_timeout
shard_block_id
: string
message_id
: string
message_dst
: string
message
: string
Notifies the app that the message was not executed within expire timeout on-chain and will never be because it is already expired. The expiration timeout can be configured with AbiConfig
parameters.
This event occurs only for the contracts which ABI includes "expire" header.
If Application specifies NetworkConfig.message_retries_count
> 0, then process_message
will perform retries: will create a new message and send it again and repeat it until it reaches the maximum retries count or receives a successful result. All the processing events will be repeated.
message_id
: string
message_dst
: string
message
: string
Notifies the app that the message has been delivered to the thread's validators
message_id
: string
message_dst
: string
timestamp
: bigint
json
: any
Notifies the app that the message has been successfully included into a block candidate by the thread's collator
message_id
: string
message_dst
: string
timestamp
: bigint
json
: any
Notifies the app that the block candidate with the message has been accepted by the thread's validators
message_id
: string
message_dst
: string
timestamp
: bigint
json
: any
Notifies the app about some other minor REMP statuses occurring during message processing
message_id
: string
message_dst
: string
timestamp
: bigint
json
: any
Notifies the app about any problem that has occurred in REMP processing - in this case library switches to the fallback transaction awaiting scenario (sequential block reading).
message_id
: string
message_dst
: string
Depends on value of the type
field.
When type is 'WillFetchFirstBlock'
Notifies the application that the account's current shard block will be fetched from the network. This step is performed before the message sending so that sdk knows starting from which block it will search for the transaction.
Fetched block will be used later in waiting phase.
message_id
: string
message_dst
: string
When type is 'FetchFirstBlockFailed'
Notifies the app that the client has failed to fetch the account's current shard block.
This may happen due to the network issues. Receiving this event means that message processing will not proceed - message was not sent, and Developer can try to run process_message
again, in the hope that the connection is restored.
message_id
: string
message_dst
: string
When type is 'WillSend'
Notifies the app that the message will be sent to the network. This event means that the account's current shard block was successfully fetched and the message was successfully created (abi.encode_message
function was executed successfully).
shard_block_id
: string
message_id
: string
message_dst
: string
message
: string
When type is 'DidSend'
Notifies the app that the message was sent to the network, i.e processing.send_message
was successfully executed. Now, the message is in the blockchain. If Application exits at this phase, Developer needs to proceed with processing after the application is restored with wait_for_transaction
function, passing shard_block_id and message from this event.
Do not forget to specify abi of your contract as well, it is crucial for processing. See processing.wait_for_transaction
documentation.
shard_block_id
: string
message_id
: string
message_dst
: string
message
: string
When type is 'SendFailed'
Notifies the app that the sending operation was failed with network error.
Nevertheless the processing will be continued at the waiting phase because the message possibly has been delivered to the node. If Application exits at this phase, Developer needs to proceed with processing after the application is restored with wait_for_transaction
function, passing shard_block_id and message from this event. Do not forget to specify abi of your contract as well, it is crucial for processing. See processing.wait_for_transaction
documentation.
shard_block_id
: string
message_id
: string
message_dst
: string
message
: string
When type is 'WillFetchNextBlock'
Notifies the app that the next shard block will be fetched from the network.
Event can occurs more than one time due to block walking procedure. If Application exits at this phase, Developer needs to proceed with processing after the application is restored with wait_for_transaction
function, passing shard_block_id and message from this event. Do not forget to specify abi of your contract as well, it is crucial for processing. See processing.wait_for_transaction
documentation.
shard_block_id
: string
message_id
: string
message_dst
: string
message
: string
When type is 'FetchNextBlockFailed'
Notifies the app that the next block can't be fetched.
If no block was fetched within NetworkConfig.wait_for_timeout
then processing stops. This may happen when the shard stops, or there are other network issues. In this case Developer should resume message processing with wait_for_transaction
, passing shard_block_id, message and contract abi to it. Note that passing ABI is crucial, because it will influence the processing strategy.
Another way to tune this is to specify long timeout in NetworkConfig.wait_for_timeout
shard_block_id
: string
message_id
: string
message_dst
: string
message
: string
When type is 'MessageExpired'
Notifies the app that the message was not executed within expire timeout on-chain and will never be because it is already expired. The expiration timeout can be configured with AbiConfig
parameters.
This event occurs only for the contracts which ABI includes "expire" header.
If Application specifies NetworkConfig.message_retries_count
> 0, then process_message
will perform retries: will create a new message and send it again and repeat it until it reaches the maximum retries count or receives a successful result. All the processing events will be repeated.
message_id
: string
message_dst
: string
message
: string
When type is 'RempSentToValidators'
Notifies the app that the message has been delivered to the thread's validators
message_id
: string
message_dst
: string
timestamp
: bigint
json
: any
When type is 'RempIncludedIntoBlock'
Notifies the app that the message has been successfully included into a block candidate by the thread's collator
message_id
: string
message_dst
: string
timestamp
: bigint
json
: any
When type is 'RempIncludedIntoAcceptedBlock'
Notifies the app that the block candidate with the message has been accepted by the thread's validators
message_id
: string
message_dst
: string
timestamp
: bigint
json
: any
When type is 'RempOther'
Notifies the app about some other minor REMP statuses occurring during message processing
message_id
: string
message_dst
: string
timestamp
: bigint
json
: any
When type is 'RempError'
Notifies the app about any problem that has occurred in REMP processing - in this case library switches to the fallback transaction awaiting scenario (sequential block reading).
message_id
: string
message_dst
: string
Variant constructors:
transaction
: any – Parsed transaction.
In addition to the regular transaction fields there is a
boc
field encoded with base64
which contains source
transaction BOC.
out_messages
: string[] – List of output messages' BOCs.
Encoded as base64
output
?: any – Decoded body of the function output message.
exit_code
: number – Compute phase exit code.
hash
?: string – Hash of the transaction. Present if transaction was included into the blocks. When then transaction was emulated this field will be missing.
aborted
: boolean – Aborted field of the transaction.
wait_until
: number – Block time Must be specified as a UNIX timestamp in seconds
user_data
?: any – User defined data associated with this message. Helps to identify this message when user received MessageMonitoringResult
.
hash
: string – Hash of the message.
error
?: string – In case of Timeout
contains possible error reason.
user_data
?: any – User defined data related to this message. This is the same value as passed before with MessageMonitoringParams
or SendMessageParams
.
One of the following value:
AtLeastOne = "AtLeastOne"
– If there are no resolved results yet, then monitor awaits for the next resolved result.
All = "All"
– Monitor waits until all unresolved messages will be resolved. If there are no unresolved messages then monitor will wait.
NoWait = "NoWait"
BOC of the message.
boc
: string
Message's hash and destination address.
hash
: string – Hash of the message.
address
: string – Destination address of the message.
Depends on value of the type
field.
When type is 'Boc'
BOC of the message.
boc
: string
When type is 'HashAddress'
Message's hash and destination address.
hash
: string – Hash of the message.
address
: string – Destination address of the message.
Variant constructors:
One of the following value:
Finalized = "Finalized"
– Returned when the messages was processed and included into finalized block before wait_until
block time.
Timeout = "Timeout"
– Returned when the message was not processed until wait_until
block time.
Reserved = "Reserved"
– Reserved for future statuses.
Is never returned. Application should wait for one of the Finalized
or Timeout
statuses.
All other statuses are intermediate.
boc
: string – BOC of the message, that must be sent to the blockchain.
wait_until
: number – Expiration time of the message. Must be specified as a UNIX timestamp in seconds.
user_data
?: any – User defined data associated with this message. Helps to identify this message when user received MessageMonitoringResult
.
queue
: string – Name of the monitoring queue.
queue
: string – Name of the monitoring queue.
unresolved
: number – Count of the unresolved messages.
resolved
: number – Count of resolved results.
queue
: string – Name of the monitoring queue.
queue
: string – Name of the monitoring queue.
monitor_queue
?: string – Optional message monitor queue that starts monitoring for the processing results for sent messages.
message
: string – Message BOC.
send_events
?: boolean – Flag for requesting events sending. Default is false
.
shard_block_id
: string – The last generated shard block of the message destination account before the message was sent.
This block id must be used as a parameter of the
wait_for_transaction
.
sending_endpoints
: string[] – The list of endpoints to which the message was sent.
This list id must be used as a parameter of the
wait_for_transaction
.
message
: string – Message BOC.
Encoded with base64
.
shard_block_id
: string – The last generated block id of the destination account shard before the message was sent.
You must provide the same value as the send_message
has returned.
send_events
?: boolean – Flag that enables/disables intermediate events. Default is false
.
sending_endpoints
?: string[] – The list of endpoints to which the message was sent.
Use this field to get more informative errors.
Provide the same value as the send_message
has returned.
If the message was not delivered (expired), SDK will log the endpoint URLs, used for its sending.
send_events
?: boolean – Flag for requesting events sending. Default is false
.
– Notifies the app that the client has failed to fetch the account's current shard block.
– Notifies the app that the message will be sent to the network. This event means that the account's current shard block was successfully fetched and the message was successfully created (abi.encode_message
function was executed successfully).
– Notifies the app that the message was sent to the network, i.e processing.send_message
was successfully executed. Now, the message is in the blockchain. If Application exits at this phase, Developer needs to proceed with processing after the application is restored with wait_for_transaction
function, passing shard_block_id and message from this event.
– Notifies the app that the sending operation was failed with network error.
– Notifies the app that the next shard block will be fetched from the network.
– Notifies the app that the next block can't be fetched.
– Notifies the app that the message was not executed within expire timeout on-chain and will never be because it is already expired. The expiration timeout can be configured with AbiConfig
parameters.
– Notifies the app that the message has been delivered to the thread's validators
– Notifies the app that the message has been successfully included into a block candidate by the thread's collator
– Notifies the app that the block candidate with the message has been accepted by the thread's validators
– Notifies the app about some other minor REMP statuses occurring during message processing
– Notifies the app about any problem that has occurred in REMP processing - in this case library switches to the fallback transaction awaiting scenario (sequential block reading).
– BOC of the message.
– Message's hash and destination address.
messages
: [] – Messages to start monitoring for.
wait_mode
?: – Wait mode.
Default is NO_WAIT
.
results
: [] – List of the resolved results.
messages
: [] – Messages that must be sent to the blockchain.
messages
: [] – Messages that was sent to the blockchain for execution.
abi
?: – Optional message ABI.
If this parameter is specified and the message has the
expire
header then expiration time will be checked against
the current time to prevent unnecessary sending of already expired message.
The message already expired
error will be returned in this
case.
Note, that specifying abi
for ABI compliant contracts is
strongly recommended, so that proper processing strategy can be
chosen.
responseHandler
?: – additional responses handler.
abi
?: – Optional ABI for decoding the transaction result.
If it is specified, then the output messages' bodies will be
decoded according to this ABI.
The abi_decoded
result field will be filled out.
responseHandler
?: – additional responses handler.
decoded
?: – Optional decoded message bodies according to the optional abi
parameter.
fees
: – Transaction fees
message_encode_params
: – Message encode parameters.
responseHandler
?: – additional responses handler.
decoded
?: – Optional decoded message bodies according to the optional abi
parameter.
fees
: – Transaction fees
error
:
error
:
error
:
error
:
error
:
error
:
error
:
error
:
error
:
error
:
decoded
?: – Optional decoded message bodies according to the optional abi
parameter.
fees
: – Transaction fees
out_messages
: ?[] – Decoded bodies of the out messages.
If the message can't be decoded, then None
will be stored in
the appropriate position.
compute
?: – Optional information about the compute phase of the transaction.
message
: – Monitored message identification. Can be provided as a message's BOC or (hash, address) pair. BOC is a preferable way because it helps to determine possible error reason (using TVM execution of the message).
status
: – Processing status.
transaction
?: – In case of Finalized
the transaction is extracted from the block. In case of Timeout
the transaction is emulated using the last known account state.
messages
: [] – Messages to start monitoring for.
wait_mode
?: – Wait mode.
Default is NO_WAIT
.
results
: [] – List of the resolved results.
messages
: [] – Messages that must be sent to the blockchain.
messages
: [] – Messages that was sent to the blockchain for execution.
abi
?: – Optional message ABI.
If this parameter is specified and the message has the
expire
header then expiration time will be checked against
the current time to prevent unnecessary sending of already expired message.
The message already expired
error will be returned in this
case.
Note, that specifying abi
for ABI compliant contracts is
strongly recommended, so that proper processing strategy can be
chosen.
abi
?: – Optional ABI for decoding the transaction result.
If it is specified, then the output messages' bodies will be
decoded according to this ABI.
The abi_decoded
result field will be filled out.
message_encode_params
: – Message encode parameters.