everscale-client-ruby 1.1.61 → 1.1.62

Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: 35aafe4b89235753c799f0e51e0af5ed72f7cbdc34a820de78af3151c4e16e97
4
- data.tar.gz: 70b20ef01342703a740d4c90278af3fc59233329134da50f6d75775ddfb1b6ab
3
+ metadata.gz: 2a2bab7f5d6d74b7d68602ecf6b77c0a999de5900dfa7ad4b02c812cd2eceb1e
4
+ data.tar.gz: 47848c0c8c8cc1b44e8a6b24200f06fbf33bd91342448205a45c9cd9562bde0c
5
5
  SHA512:
6
- metadata.gz: 5d8a8277c2be0d8f4173387498ef2a88f7e065915ffbe33f479ebaa162693d5e74cbb005dd906b1809478aab812ac8f9e5eed85c36734e49771af3bc6a99d749
7
- data.tar.gz: 2faf3ef66d975b9ab1733626b66967e29aaabd30356559ac2722505e98afbdbae57d52f0d60b9eef3b958ada37f88ab678e5e1aeabed8fb1f7ba16879f13039d
6
+ metadata.gz: 8b65048731697859466883fbd71fe0eefcabc812fb39464a14b9e403b04f6a94ad33fd42921c1d8a095a88f2f0780ef257cef119d70a7d189df3badced88c8c0
7
+ data.tar.gz: 9125a9353c68f040e3e9122c69a6ebcbc6f0a21b06872439bfb776559e190b0b051e557164f481b0207ca55f63098c4a66031a00e07b546ae7ee05dd18355bd8
@@ -1,5 +1,5 @@
1
1
  {
2
- "version": "1.38.0",
2
+ "version": "1.39.0",
3
3
  "modules": [
4
4
  {
5
5
  "name": "client",
@@ -477,7 +477,7 @@
477
477
  "number_size": 32
478
478
  },
479
479
  "summary": "Frequency of sync latency detection.",
480
- "description": "Library periodically checks the current endpoint for blockchain data syncronization latency.\nIf the latency (time-lag) is less then `NetworkConfig.max_latency`\nthen library selects another endpoint.\n\nMust be specified in milliseconds. Default is 60000 (1 min)."
480
+ "description": "Library periodically checks the current endpoint for blockchain data synchronization latency.\nIf the latency (time-lag) is less then `NetworkConfig.max_latency`\nthen library selects another endpoint.\n\nMust be specified in milliseconds. Default is 60000 (1 min)."
481
481
  },
482
482
  {
483
483
  "name": "max_latency",
@@ -487,7 +487,7 @@
487
487
  "number_type": "UInt",
488
488
  "number_size": 32
489
489
  },
490
- "summary": "Maximum value for the endpoint's blockchain data syncronization latency (time-lag). Library periodically checks the current endpoint for blockchain data synchronization latency. If the latency (time-lag) is less then `NetworkConfig.max_latency` then library selects another endpoint.",
490
+ "summary": "Maximum value for the endpoint's blockchain data synchronization latency (time-lag). Library periodically checks the current endpoint for blockchain data synchronization latency. If the latency (time-lag) is less then `NetworkConfig.max_latency` then library selects another endpoint.",
491
491
  "description": "Must be specified in milliseconds. Default is 60000 (1 min)."
492
492
  },
493
493
  {
@@ -520,7 +520,7 @@
520
520
  "number_size": 32
521
521
  },
522
522
  "summary": "UNSTABLE.",
523
- "description": "First REMP status awaiting timeout. If no status recieved during the timeout than fallback transaction scenario is activated.\n\nMust be specified in milliseconds. Default is 1000 (1 sec)."
523
+ "description": "First REMP status awaiting timeout. If no status received during the timeout than fallback transaction scenario is activated.\n\nMust be specified in milliseconds. Default is 1000 (1 sec)."
524
524
  },
525
525
  {
526
526
  "name": "next_remp_status_timeout",
@@ -531,7 +531,7 @@
531
531
  "number_size": 32
532
532
  },
533
533
  "summary": "UNSTABLE.",
534
- "description": "Subsequent REMP status awaiting timeout. If no status recieved during the timeout than fallback transaction scenario is activated.\n\nMust be specified in milliseconds. Default is 5000 (5 sec)."
534
+ "description": "Subsequent REMP status awaiting timeout. If no status received during the timeout than fallback transaction scenario is activated.\n\nMust be specified in milliseconds. Default is 5000 (5 sec)."
535
535
  },
536
536
  {
537
537
  "name": "access_key",
@@ -559,7 +559,7 @@
559
559
  {
560
560
  "name": "WS",
561
561
  "type": "None",
562
- "summary": "All GraphQL queries will be served using single web socket connection.",
562
+ "summary": "All GraphQL queries will be served using single web socket connection. SDK is tested to reliably handle 5000 parallel network requests (sending and processing messages, quering and awaiting blockchain data)",
563
563
  "description": null
564
564
  }
565
565
  ],
@@ -6133,6 +6133,26 @@
6133
6133
  "summary": null,
6134
6134
  "description": null
6135
6135
  },
6136
+ {
6137
+ "name": "DataLayout",
6138
+ "type": "EnumOfConsts",
6139
+ "enum_consts": [
6140
+ {
6141
+ "name": "Input",
6142
+ "type": "None",
6143
+ "summary": "Decode message body as function input parameters.",
6144
+ "description": null
6145
+ },
6146
+ {
6147
+ "name": "Output",
6148
+ "type": "None",
6149
+ "summary": "Decode message body as function output.",
6150
+ "description": null
6151
+ }
6152
+ ],
6153
+ "summary": null,
6154
+ "description": null
6155
+ },
6136
6156
  {
6137
6157
  "name": "ParamsOfEncodeMessageBody",
6138
6158
  "type": "Struct",
@@ -6539,6 +6559,25 @@
6539
6559
  },
6540
6560
  "summary": "Flag allowing partial BOC decoding when ABI doesn't describe the full body BOC. Controls decoder behaviour when after decoding all described in ABI params there are some data left in BOC: `true` - return decoded values `false` - return error of incomplete BOC deserialization (default)",
6541
6561
  "description": null
6562
+ },
6563
+ {
6564
+ "name": "function_name",
6565
+ "type": "Optional",
6566
+ "optional_inner": {
6567
+ "type": "String"
6568
+ },
6569
+ "summary": "Function name or function id if is known in advance",
6570
+ "description": null
6571
+ },
6572
+ {
6573
+ "name": "data_layout",
6574
+ "type": "Optional",
6575
+ "optional_inner": {
6576
+ "type": "Ref",
6577
+ "ref_name": "abi.DataLayout"
6578
+ },
6579
+ "summary": null,
6580
+ "description": null
6542
6581
  }
6543
6582
  ],
6544
6583
  "summary": null,
@@ -6616,6 +6655,25 @@
6616
6655
  },
6617
6656
  "summary": "Flag allowing partial BOC decoding when ABI doesn't describe the full body BOC. Controls decoder behaviour when after decoding all described in ABI params there are some data left in BOC: `true` - return decoded values `false` - return error of incomplete BOC deserialization (default)",
6618
6657
  "description": null
6658
+ },
6659
+ {
6660
+ "name": "function_name",
6661
+ "type": "Optional",
6662
+ "optional_inner": {
6663
+ "type": "String"
6664
+ },
6665
+ "summary": "Function name or function id if is known in advance",
6666
+ "description": null
6667
+ },
6668
+ {
6669
+ "name": "data_layout",
6670
+ "type": "Optional",
6671
+ "optional_inner": {
6672
+ "type": "Ref",
6673
+ "ref_name": "abi.DataLayout"
6674
+ },
6675
+ "summary": null,
6676
+ "description": null
6619
6677
  }
6620
6678
  ],
6621
6679
  "summary": null,
@@ -7776,7 +7834,7 @@
7776
7834
  {
7777
7835
  "name": "id",
7778
7836
  "type": "String",
7779
- "summary": "Shardstate identificator",
7837
+ "summary": "Shardstate identifier",
7780
7838
  "description": null
7781
7839
  },
7782
7840
  {
@@ -9464,8 +9522,8 @@
9464
9522
  "description": null
9465
9523
  }
9466
9524
  ],
9467
- "summary": "Notifies the app that the message was sent to the network, i.e `processing.send_message` was successfuly 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.",
9468
- "description": "Do not forget to specify abi of your contract as well, it is crucial for proccessing. See `processing.wait_for_transaction` documentation."
9525
+ "summary": "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.",
9526
+ "description": "Do not forget to specify abi of your contract as well, it is crucial for processing. See `processing.wait_for_transaction` documentation."
9469
9527
  },
9470
9528
  {
9471
9529
  "name": "SendFailed",
@@ -9498,7 +9556,7 @@
9498
9556
  }
9499
9557
  ],
9500
9558
  "summary": "Notifies the app that the sending operation was failed with network error.",
9501
- "description": "Nevertheless the processing will be continued at the waiting\nphase because the message possibly has been delivered to the\nnode.\nIf Application exits at this phase, Developer needs to proceed with processing\nafter the application is restored with `wait_for_transaction` function, passing\nshard_block_id and message from this event. Do not forget to specify abi of your contract\nas well, it is crucial for proccessing. See `processing.wait_for_transaction` documentation."
9559
+ "description": "Nevertheless the processing will be continued at the waiting\nphase because the message possibly has been delivered to the\nnode.\nIf Application exits at this phase, Developer needs to proceed with processing\nafter the application is restored with `wait_for_transaction` function, passing\nshard_block_id and message from this event. Do not forget to specify abi of your contract\nas well, it is crucial for processing. See `processing.wait_for_transaction` documentation."
9502
9560
  },
9503
9561
  {
9504
9562
  "name": "WillFetchNextBlock",
@@ -9524,7 +9582,7 @@
9524
9582
  }
9525
9583
  ],
9526
9584
  "summary": "Notifies the app that the next shard block will be fetched from the network.",
9527
- "description": "Event can occurs more than one time due to block walking\nprocedure.\nIf Application exits at this phase, Developer needs to proceed with processing\nafter the application is restored with `wait_for_transaction` function, passing\nshard_block_id and message from this event. Do not forget to specify abi of your contract\nas well, it is crucial for proccessing. See `processing.wait_for_transaction` documentation."
9585
+ "description": "Event can occurs more than one time due to block walking\nprocedure.\nIf Application exits at this phase, Developer needs to proceed with processing\nafter the application is restored with `wait_for_transaction` function, passing\nshard_block_id and message from this event. Do not forget to specify abi of your contract\nas well, it is crucial for processing. See `processing.wait_for_transaction` documentation."
9528
9586
  },
9529
9587
  {
9530
9588
  "name": "FetchNextBlockFailed",
@@ -9584,7 +9642,7 @@
9584
9642
  }
9585
9643
  ],
9586
9644
  "summary": "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.",
9587
- "description": "This event occurs only for the contracts which ABI includes \"expire\" header.\n\nIf Application specifies `NetworkConfig.message_retries_count` > 0, then `process_message`\nwill perform retries: will create a new message and send it again and repeat it untill it reaches\nthe maximum retries count or receives a successful result. All the processing\nevents will be repeated."
9645
+ "description": "This event occurs only for the contracts which ABI includes \"expire\" header.\n\nIf Application specifies `NetworkConfig.message_retries_count` > 0, then `process_message`\nwill perform retries: will create a new message and send it again and repeat it until it reaches\nthe maximum retries count or receives a successful result. All the processing\nevents will be repeated."
9588
9646
  },
9589
9647
  {
9590
9648
  "name": "RempSentToValidators",
@@ -9670,7 +9728,7 @@
9670
9728
  "description": null
9671
9729
  }
9672
9730
  ],
9673
- "summary": "Notifies the app that the block candicate with the message has been accepted by the thread's validators",
9731
+ "summary": "Notifies the app that the block candidate with the message has been accepted by the thread's validators",
9674
9732
  "description": null
9675
9733
  },
9676
9734
  {
@@ -9714,7 +9772,7 @@
9714
9772
  "description": null
9715
9773
  }
9716
9774
  ],
9717
- "summary": "Notifies the app about any problem that has occured in REMP processing - in this case library switches to the fallback transaction awaiting scenario (sequential block reading).",
9775
+ "summary": "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).",
9718
9776
  "description": null
9719
9777
  }
9720
9778
  ],
@@ -11084,7 +11142,7 @@
11084
11142
  {
11085
11143
  "name": "run_executor",
11086
11144
  "summary": "Emulates all the phases of contract execution locally",
11087
- "description": "Performs all the phases of contract execution on Transaction Executor -\nthe same component that is used on Validator Nodes.\n\nCan be used for contract debugging, to find out the reason why a message was not delivered successfully.\nValidators throw away the failed external inbound messages (if they failed bedore `ACCEPT`) in the real network.\nThis is why these messages are impossible to debug in the real network.\nWith the help of run_executor you can do that. In fact, `process_message` function\nperforms local check with `run_executor` if there was no transaction as a result of processing\nand returns the error, if there is one.\n\nAnother use case to use `run_executor` is to estimate fees for message execution.\nSet `AccountForExecutor::Account.unlimited_balance`\nto `true` so that emulation will not depend on the actual balance.\nThis may be needed to calculate deploy fees for an account that does not exist yet.\nJSON with fees is in `fees` field of the result.\n\nOne more use case - you can produce the sequence of operations,\nthus emulating the sequential contract calls locally.\nAnd so on.\n\nTransaction executor requires account BOC (bag of cells) as a parameter.\nTo get the account BOC - use `net.query` method to download it from GraphQL API\n(field `boc` of `account`) or generate it with `abi.encode_account` method.\n\nAlso it requires message BOC. To get the message BOC - use `abi.encode_message` or `abi.encode_internal_message`.\n\nIf you need this emulation to be as precise as possible (for instance - emulate transaction\nwith particular lt in particular block or use particular blockchain config,\ndownloaded from a particular key block - then specify `execution_options` parameter.\n\nIf you need to see the aborted transaction as a result, not as an error, set `skip_transaction_check` to `true`.",
11145
+ "description": "Performs all the phases of contract execution on Transaction Executor -\nthe same component that is used on Validator Nodes.\n\nCan be used for contract debugging, to find out the reason why a message was not delivered successfully.\nValidators throw away the failed external inbound messages (if they failed before `ACCEPT`) in the real network.\nThis is why these messages are impossible to debug in the real network.\nWith the help of run_executor you can do that. In fact, `process_message` function\nperforms local check with `run_executor` if there was no transaction as a result of processing\nand returns the error, if there is one.\n\nAnother use case to use `run_executor` is to estimate fees for message execution.\nSet `AccountForExecutor::Account.unlimited_balance`\nto `true` so that emulation will not depend on the actual balance.\nThis may be needed to calculate deploy fees for an account that does not exist yet.\nJSON with fees is in `fees` field of the result.\n\nOne more use case - you can produce the sequence of operations,\nthus emulating the sequential contract calls locally.\nAnd so on.\n\nTransaction executor requires account BOC (bag of cells) as a parameter.\nTo get the account BOC - use `net.query` method to download it from GraphQL API\n(field `boc` of `account`) or generate it with `abi.encode_account` method.\n\nAlso it requires message BOC. To get the message BOC - use `abi.encode_message` or `abi.encode_internal_message`.\n\nIf you need this emulation to be as precise as possible (for instance - emulate transaction\nwith particular lt in particular block or use particular blockchain config,\ndownloaded from a particular key block - then specify `execution_options` parameter.\n\nIf you need to see the aborted transaction as a result, not as an error, set `skip_transaction_check` to `true`.",
11088
11146
  "params": [
11089
11147
  {
11090
11148
  "name": "context",
@@ -11310,6 +11368,20 @@
11310
11368
  "value": "615",
11311
11369
  "summary": null,
11312
11370
  "description": null
11371
+ },
11372
+ {
11373
+ "name": "QueryTransactionTreeTimeout",
11374
+ "type": "Number",
11375
+ "value": "616",
11376
+ "summary": null,
11377
+ "description": null
11378
+ },
11379
+ {
11380
+ "name": "GraphqlConnectionError",
11381
+ "type": "Number",
11382
+ "value": "617",
11383
+ "summary": null,
11384
+ "description": null
11313
11385
  }
11314
11386
  ],
11315
11387
  "summary": null,
@@ -12049,7 +12121,18 @@
12049
12121
  "number_size": 32
12050
12122
  },
12051
12123
  "summary": "Timeout used to limit waiting time for the missing messages and transaction.",
12052
- "description": "If some of the following messages and transactions are missing yet\nThe maximum waiting time is regulated by this option.\n\nDefault value is 60000 (1 min)."
12124
+ "description": "If some of the following messages and transactions are missing yet\nThe maximum waiting time is regulated by this option.\n\nDefault value is 60000 (1 min). If `timeout` is set to 0 then function will wait infinitely\nuntil the whole transaction tree is executed"
12125
+ },
12126
+ {
12127
+ "name": "transaction_max_count",
12128
+ "type": "Optional",
12129
+ "optional_inner": {
12130
+ "type": "Number",
12131
+ "number_type": "UInt",
12132
+ "number_size": 32
12133
+ },
12134
+ "summary": "Maximum transaction count to wait.",
12135
+ "description": "If transaction tree contains more transaction then this parameter then only first `transaction_max_count` transaction are awaited and returned.\n\nDefault value is 50. If `transaction_max_count` is set to 0 then no limitation on\ntransaction count is used and all transaction are returned."
12053
12136
  }
12054
12137
  ],
12055
12138
  "summary": null,
@@ -12617,7 +12700,7 @@
12617
12700
  {
12618
12701
  "name": "subscribe",
12619
12702
  "summary": "Creates a subscription",
12620
- "description": "The subscription is a persistent communication channel between\nclient and Everscale Network.\n\n### Important Notes on Subscriptions\n\nUnfortunately sometimes the connection with the network breakes down.\nIn this situation the library attempts to reconnect to the network.\nThis reconnection sequence can take significant time.\nAll of this time the client is disconnected from the network.\n\nBad news is that all changes that happened while\nthe client was disconnected are lost.\n\nGood news is that the client report errors to the callback when\nit loses and resumes connection.\n\nSo, if the lost changes are important to the application then\nthe application must handle these error reports.\n\nLibrary reports errors with `responseType` == 101\nand the error object passed via `params`.\n\nWhen the library has successfully reconnected\nthe application receives callback with\n`responseType` == 101 and `params.code` == 614 (NetworkModuleResumed).\n\nApplication can use several ways to handle this situation:\n- If application monitors changes for the single\nobject (for example specific account): application\ncan perform a query for this object and handle actual data as a\nregular data from the subscription.\n- If application monitors sequence of some objects\n(for example transactions of the specific account): application must\nrefresh all cached (or visible to user) lists where this sequences presents.",
12703
+ "description": "The subscription is a persistent communication channel between\nclient and Everscale Network.\n\n### Important Notes on Subscriptions\n\nUnfortunately sometimes the connection with the network breaks down.\nIn this situation the library attempts to reconnect to the network.\nThis reconnection sequence can take significant time.\nAll of this time the client is disconnected from the network.\n\nBad news is that all changes that happened while\nthe client was disconnected are lost.\n\nGood news is that the client report errors to the callback when\nit loses and resumes connection.\n\nSo, if the lost changes are important to the application then\nthe application must handle these error reports.\n\nLibrary reports errors with `responseType` == 101\nand the error object passed via `params`.\n\nWhen the library has successfully reconnected\nthe application receives callback with\n`responseType` == 101 and `params.code` == 614 (NetworkModuleResumed).\n\nApplication can use several ways to handle this situation:\n- If application monitors changes for the single\nobject (for example specific account): application\ncan perform a query for this object and handle actual data as a\nregular data from the subscription.\n- If application monitors sequence of some objects\n(for example transactions of the specific account): application must\nrefresh all cached (or visible to user) lists where this sequences presents.",
12621
12704
  "params": [
12622
12705
  {
12623
12706
  "name": "context",
@@ -12903,7 +12986,7 @@
12903
12986
  {
12904
12987
  "name": "query_transaction_tree",
12905
12988
  "summary": "Returns a tree of transactions triggered by a specific message.",
12906
- "description": "Performs recursive retrieval of a transactions tree produced by a specific message:\nin_msg -> dst_transaction -> out_messages -> dst_transaction -> ...\nIf the chain of transactions execution is in progress while the function is running,\nit will wait for the next transactions to appear until the full tree or more than 50 transactions\nare received.\n\nAll the retrieved messages and transactions are included\ninto `result.messages` and `result.transactions` respectively.\n\nFunction reads transactions layer by layer, by pages of 20 transactions.\n\nThe retrieval prosess goes like this:\nLet's assume we have an infinite chain of transactions and each transaction generates 5 messages.\n1. Retrieve 1st message (input parameter) and corresponding transaction - put it into result.\nIt is the first level of the tree of transactions - its root.\nRetrieve 5 out message ids from the transaction for next steps.\n2. Retrieve 5 messages and corresponding transactions on the 2nd layer. Put them into result.\nRetrieve 5*5 out message ids from these transactions for next steps\n3. Retrieve 20 (size of the page) messages and transactions (3rd layer) and 20*5=100 message ids (4th layer).\n4. Retrieve the last 5 messages and 5 transactions on the 3rd layer + 15 messages and transactions (of 100) from the 4th layer\n+ 25 message ids of the 4th layer + 75 message ids of the 5th layer.\n5. Retrieve 20 more messages and 20 more transactions of the 4th layer + 100 more message ids of the 5th layer.\n6. Now we have 1+5+20+20+20 = 66 transactions, which is more than 50. Function exits with the tree of\n1m->1t->5m->5t->25m->25t->35m->35t. If we see any message ids in the last transactions out_msgs, which don't have\ncorresponding messages in the function result, it means that the full tree was not received and we need to continue iteration.\n\nTo summarize, it is guaranteed that each message in `result.messages` has the corresponding transaction\nin the `result.transactions`.\nBut there is no guarantee that all messages from transactions `out_msgs` are\npresented in `result.messages`.\nSo the application has to continue retrieval for missing messages if it requires.",
12989
+ "description": "Performs recursive retrieval of a transactions tree produced by a specific message:\nin_msg -> dst_transaction -> out_messages -> dst_transaction -> ...\nIf the chain of transactions execution is in progress while the function is running,\nit will wait for the next transactions to appear until the full tree or more than 50 transactions\nare received.\n\nAll the retrieved messages and transactions are included\ninto `result.messages` and `result.transactions` respectively.\n\nFunction reads transactions layer by layer, by pages of 20 transactions.\n\nThe retrieval process goes like this:\nLet's assume we have an infinite chain of transactions and each transaction generates 5 messages.\n1. Retrieve 1st message (input parameter) and corresponding transaction - put it into result.\nIt is the first level of the tree of transactions - its root.\nRetrieve 5 out message ids from the transaction for next steps.\n2. Retrieve 5 messages and corresponding transactions on the 2nd layer. Put them into result.\nRetrieve 5*5 out message ids from these transactions for next steps\n3. Retrieve 20 (size of the page) messages and transactions (3rd layer) and 20*5=100 message ids (4th layer).\n4. Retrieve the last 5 messages and 5 transactions on the 3rd layer + 15 messages and transactions (of 100) from the 4th layer\n+ 25 message ids of the 4th layer + 75 message ids of the 5th layer.\n5. Retrieve 20 more messages and 20 more transactions of the 4th layer + 100 more message ids of the 5th layer.\n6. Now we have 1+5+20+20+20 = 66 transactions, which is more than 50. Function exits with the tree of\n1m->1t->5m->5t->25m->25t->35m->35t. If we see any message ids in the last transactions out_msgs, which don't have\ncorresponding messages in the function result, it means that the full tree was not received and we need to continue iteration.\n\nTo summarize, it is guaranteed that each message in `result.messages` has the corresponding transaction\nin the `result.transactions`.\nBut there is no guarantee that all messages from transactions `out_msgs` are\npresented in `result.messages`.\nSo the application has to continue retrieval for missing messages if it requires.",
12907
12990
  "params": [
12908
12991
  {
12909
12992
  "name": "context",
@@ -12979,7 +13062,7 @@
12979
13062
  {
12980
13063
  "name": "resume_block_iterator",
12981
13064
  "summary": "Resumes block iterator.",
12982
- "description": "The iterator stays exactly at the same position where the `resume_state` was catched.\n\nApplication should call the `remove_iterator` when iterator is no longer required.",
13065
+ "description": "The iterator stays exactly at the same position where the `resume_state` was caught.\n\nApplication should call the `remove_iterator` when iterator is no longer required.",
12983
13066
  "params": [
12984
13067
  {
12985
13068
  "name": "context",
@@ -80,18 +80,35 @@ client = TonClient.create(config: {network: {endpoints: ["https://eri01.net.ever
80
80
 
81
81
  # All methods are asynchronous
82
82
 
83
- # example: call method for Crypto module
83
+ ## example 1: call method for Crypto module
84
84
  payload = {composite: '17ED48941A08F981'}
85
85
 
86
86
  # Sync
87
87
  response = client.crypto.factorize_sync(payload)
88
- p response
88
+ p response['result']['factors']
89
89
 
90
90
  # Async
91
91
  client.crypto.factorize(payload) do |response|
92
92
  p response.result['factors']
93
93
  end
94
94
 
95
+
96
+ ## example 2: parse message from boc base64 encoded
97
+ payload = {boc: "te6ccgEBAQEAWAAAq2n+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE/zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzSsG8DgAAAAAjuOu9NAL7BxYpA"}
98
+
99
+ # Sync
100
+ response = client.boc.parse_message_sync(payload)
101
+ p response['result']['parsed']['id']
102
+ p response['result']['parsed']['src']
103
+ p response['result']['parsed']['dst']
104
+
105
+ # Async
106
+ client.boc.parse_message_sync(payload) do |response|
107
+ p response.result['parsed']['id']
108
+ p response.result['parsed']['src']
109
+ p response.result['parsed']['dst']
110
+ end
111
+
95
112
  # e.g. ...
96
113
  ```\n\n
97
114
  }
@@ -128,6 +128,8 @@ module TonClient
128
128
  # abi: Value - # # contract ABI
129
129
  # message: String - # # Message BOC
130
130
  # allow_partial: Boolean<Optional> - # # Flag allowing partial BOC decoding when ABI doesn't describe the full body BOC. Controls decoder behaviour when after decoding all described in ABI params there are some data left in BOC: `true` - return decoded values `false` - return error of incomplete BOC deserialization (default)
131
+ # function_name: String<Optional> - # # Function name or function id if is known in advance
132
+ # data_layout: DataLayout<Optional> -
131
133
  # RESPONSE: DecodedMessageBody
132
134
  # body_type: MessageBodyType - # # Type of the message body content.
133
135
  # name: String - # # Function or event name.
@@ -148,6 +150,8 @@ module TonClient
148
150
  # body: String - # # Message body BOC encoded in `base64`.
149
151
  # is_internal: Boolean - # # True if the body belongs to the internal message.
150
152
  # allow_partial: Boolean<Optional> - # # Flag allowing partial BOC decoding when ABI doesn't describe the full body BOC. Controls decoder behaviour when after decoding all described in ABI params there are some data left in BOC: `true` - return decoded values `false` - return error of incomplete BOC deserialization (default)
153
+ # function_name: String<Optional> - # # Function name or function id if is known in advance
154
+ # data_layout: DataLayout<Optional> -
151
155
  # RESPONSE: DecodedMessageBody
152
156
  # body_type: MessageBodyType - # # Type of the message body content.
153
157
  # name: String - # # Function or event name.
@@ -71,7 +71,7 @@ module TonClient
71
71
 
72
72
  # INPUT: ParamsOfParseShardstate
73
73
  # boc: String - # # BOC encoded as base64
74
- # id: String - # # Shardstate identificator
74
+ # id: String - # # Shardstate identifier
75
75
  # workchain_id: Number - # # Workchain shardstate belongs to
76
76
  # RESPONSE: ResultOfParse
77
77
  # parsed: Value - # # JSON containing parsed BOC
@@ -229,7 +229,9 @@ module TonClient
229
229
  # in_msg: String - # # Input message id.
230
230
  # abi_registry: Array<Optional> - # # List of contract ABIs that will be used to decode message bodies. Library will try to decode each returned message body using any ABI from the registry.
231
231
  # timeout: Number<Optional> - # # Timeout used to limit waiting time for the missing messages and transaction. # # If some of the following messages and transactions are missing yetThe maximum waiting time is regulated by this option.
232
- # Default value is 60000 (1 min).
232
+ # Default value is 60000 (1 min). If `timeout` is set to 0 then function will wait infinitelyuntil the whole transaction tree is executed
233
+ # transaction_max_count: Number<Optional> - # # Maximum transaction count to wait. # # If transaction tree contains more transaction then this parameter then only first `transaction_max_count` transaction are awaited and returned.
234
+ # Default value is 50. If `transaction_max_count` is set to 0 then no limitation ontransaction count is used and all transaction are returned.
233
235
  # RESPONSE: ResultOfQueryTransactionTree
234
236
  # messages: Array - # # Messages.
235
237
  # transactions: Array - # # Transactions.
@@ -1,4 +1,4 @@
1
1
  module TonClient
2
- VERSION = "1.1.61"
2
+ VERSION = "1.1.62"
3
3
  end
4
4
 
metadata CHANGED
@@ -1,14 +1,14 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: everscale-client-ruby
3
3
  version: !ruby/object:Gem::Version
4
- version: 1.1.61
4
+ version: 1.1.62
5
5
  platform: ruby
6
6
  authors:
7
7
  - nerzh
8
8
  autorequire:
9
9
  bindir: bin
10
10
  cert_chain: []
11
- date: 2022-10-23 00:00:00.000000000 Z
11
+ date: 2022-12-09 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  name: ffi