Skip to content

Commit f816b21

Browse files
committed
Fix blockchain sub-status hyperlinks, add more extensive Polygon example
Signed-off-by: Matthew Whitehead <[email protected]>
1 parent b67c3de commit f816b21

File tree

6 files changed

+1348
-104
lines changed

6 files changed

+1348
-104
lines changed

docs/architecture/blockchain_connector_framework.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -146,7 +146,7 @@ A reference implementation is provided that:
146146
The reference implementation is available [here](https://github.com/hyperledger/firefly-transaction-manager/blob/main/pkg/policyengines/simple/simple_policy_engine.go)
147147

148148
FireFly 1.2 introduced a specification for policy engines to record more detailed information about transaction sub-status and lower-level actions it performs
149-
as part of progressing a transaction onto the chain. A policy engine might for example have a sub-status of `Received` and another sub-status of `Tracking`. For more information see [Blockchain Operation Status](../reference/blockchain_operations.html)
149+
as part of progressing a transaction onto the chain. A policy engine might for example have a sub-status of `Received` and another sub-status of `Tracking`. For more information see [Blockchain Operation Status](../reference/blockchain_operation_status.html)
150150

151151

152152
## Event Streams

docs/reference/blockchain_operation_status.md

Lines changed: 152 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
22
layout: default
3-
title: pages.blockchain_operation_status
3+
title: Blockchain Operation Status
44
parent: pages.reference
55
nav_order: 5
66
---
@@ -19,7 +19,7 @@ nav_order: 5
1919

2020
## Blockchain Operations
2121

22-
Every FireFly [Transaction](./types/_includes/transaction_description.html) can involve zero or more [Operations](./types/_includes/operation_description.html). Blockchain operations are handled by the blockchain connector configured for the namespace and represent a blockchain transaction being handled by that connector.
22+
Every FireFly [Transaction](./types/transaction.html) can involve zero or more [Operations](./types/operation.html). Blockchain operations are handled by the blockchain connector configured for the namespace and represent a blockchain transaction being handled by that connector.
2323

2424
## Blockchain Operation Status
2525

@@ -29,41 +29,43 @@ FireFly 1.2 introduced the concept of sub-status types that allow a blockchain c
2929

3030
[![Sub-status diagram](../images/blockchain-sub-status.png)](../images/blockchain-sub-status.png)
3131

32-
To access detailed information about a blockchain operation FireFly 1.2 introduced a new query parameter, `fetchStatus`, to the `/transaction/{txid}/operation/{opid}` API. When FireFly receives an API request that includes the fetchStatus query parameter it makes a synchronous call directly to the blockchain connector, requesting all of blockchain transaction detail it has. This payload is then included in the FireFly transaction response under a new `detail` field.
32+
To access detailed information about a blockchain operation FireFly 1.2 introduced a new query parameter, `fetchStatus`, to the `/transaction/{txid}/operation/{opid}` API. When FireFly receives an API request that includes the fetchStatus query parameter it makes a synchronous call directly to the blockchain connector, requesting all of blockchain transaction detail it has. This payload is then included in the FireFly operation response under a new `detail` field.
3333

34-
### Example
34+
### Blockchain Operation Example
3535

3636
```json
3737
{
3838
"id": "04a8b0c4-03c2-4935-85a1-87d17cddc20a",
39+
"created": "2022-05-16T01:23:15Z",
3940
"namespace": "ns1",
4041
"tx": "99543134-769b-42a8-8be4-a5f8873f969d",
4142
"type": "blockchain_invoke",
4243
"status": "Succeeded",
4344
"plugin": "ethereum",
4445
"input": {
45-
"id": "80d89712-57f3-48fe-b085-a8cba6e0667d"
46+
// Input used to initiate the blockchain operation
4647
},
4748
"output": {
48-
"payloadRef": "QmWj3tr2aTHqnRYovhS2mQAjYneRtMWJSU4M4RdAJpJwEC"
49+
// Minimal blockchain operation data necessary
50+
// to resolve the FF transaction
4951
},
5052
"detail": {
51-
// Blockchain operation status included here
53+
// Full blockchain operation information, including sub-status
54+
// transitions that took place for the operation to succeed.
5255
}
53-
"created": "2022-05-16T01:23:15Z"
5456
}
5557
```
5658

57-
## Status Structure
59+
## Detail Status Structure
5860

59-
The structure of a blockchain operation follows the structure described in [Operations](./types/_includes/operation_description.html). In FireFly 1.2, 2 new attributes were added to that structure to allow more detailed status information to be recorded:
61+
The structure of a blockchain operation follows the structure described in [Operations](./types/operation.html). In FireFly 1.2, 2 new attributes were added to that structure to allow more detailed status information to be recorded:
6062

6163
- **history** an ordered list of status changes that have taken place during processing of the transaction
6264
- **historySummary** an un-ordered list any sub-status type that the blockchain connector uses, and any action type that the blockchain connector carries out as part of processing the transaction.
6365

6466
The `history` field is designed to record an ordered list of sub-status changes that the transaction has gone through. Within each sub-status change are the actions that have been carried out to try and move the transaction on to a new sub-status. Some transactions might spend a long time going looping between different sub-status types so this field records the N most recent sub-status changes (where the size of N is determined by blockchain connector and its configuration). The follow example shows a transaction going starting at `Received`, moving to `Tracking`, and finally ending up as `Confirmed`. In order to move from `Received` to `Tracking` several actions were performed: `AssignNonce`, `RetrieveGasPrice`, and `SubmitTransaction`.
6567

66-
### Example
68+
### History Example
6769

6870
```json
6971
{
@@ -73,7 +75,7 @@ The `history` field is designed to record an ordered list of sub-status changes
7375
"history": [
7476
{
7577
"subStatus": "Received",
76-
"time": "2023-01-27T17:11:41.122965803Z"
78+
"time": "2023-01-27T17:11:41.122965803Z",
7779
"actions": [
7880
{
7981
"action": "AssignNonce",
@@ -106,7 +108,7 @@ The `history` field is designed to record an ordered list of sub-status changes
106108
},
107109
  {
108110
   "subStatus": "Tracking",
109-
"time": "2023-01-27T17:11:41.222400219Z"
111+
"time": "2023-01-27T17:11:41.222400219Z",
110112
  "actions": [
111113
    {
112114
     "action": "ReceiveReceipt",
@@ -137,7 +139,7 @@ The `history` field is designed to record an ordered list of sub-status changes
137139

138140
Because the `history` field is a FIFO structure describing the N most recent sub-status changes, some early sub-status changes or actions may be lost over time. For example an action of `assignNonce` might only happen once when the transaction is first processed by the connector. The `historySummary` field ensures that a minimal set of information is kept about every single subStatus type and action that has been recorded.
139141

140-
### Example
142+
### History Summary Example
141143

142144
```json
143145
{
@@ -194,3 +196,139 @@ Because the `history` field is a FIFO structure describing the N most recent sub
194196
]
195197
}
196198
```
199+
200+
## Public Chain Operations
201+
202+
Blockchain transactions submitted to a public chain, for example to Polygon PoS, might take longer and involve more sub-status transitions before being confirmed. One reason for this could be because of gas price fluctuations of the chain. In this case the `history` for a public blockchain operation might include a large number of `subStatus` entries. Using the example sub-status values above, a blockchain operation might move from `Tracking` to `Stale`, back to `Tracking`, back to `Stale` and so on.
203+
204+
Below is an example of the `history` for a public blockchain operation.
205+
206+
### Polygon Example
207+
208+
```json
209+
{
210+
...
211+
"lastSubmit": "2023-01-27T17:11:41.222375469Z",
212+
"nonce": "14",
213+
"history": [
214+
{
215+
"subStatus": "Received",
216+
"time": "2023-01-27T17:11:41.122965803Z",
217+
"actions": [
218+
{
219+
"action": "AssignNonce",
220+
"count": 1,
221+
"lastInfo": {
222+
  "nonce": "1"
223+
},
224+
"lastOccurrence": "2023-01-27T17:11:41.122967219Z",
225+
"time": "2023-01-27T17:11:41.122967136Z"
226+
},
227+
  {
228+
"action": "RetrieveGasPrice",
229+
"count": 1,
230+
"lastInfo": {
231+
"gasPrice": "34422243"
232+
},
233+
"lastOccurrence": "2023-01-27T17:11:41.161213303Z",
234+
"time": "2023-01-27T17:11:41.161213094Z"
235+
},
236+
{
237+
"action": "SubmitTransaction",
238+
"count": 1,
239+
  "lastInfo": {
240+
"txHash": "0x83ba5e1cf320a1d5c949082bbec8ae7fe918e6621cec39478609ec3f7deacbdb"
241+
},
242+
  "lastOccurrence": "2023-01-27T17:11:41.222374636Z",
243+
  "time": "2023-01-27T17:11:41.222374553Z"
244+
  }
245+
],
246+
},
247+
  {
248+
   "subStatus": "Tracking",
249+
"time": "2023-01-27T17:11:41.222400219Z",
250+
  "actions": [],
251+
},
252+
  {
253+
   "subStatus": "Stale",
254+
"time": "2023-01-27T17:13:21.222100434Z",
255+
  "actions": [
256+
    {
257+
     "action": "RetrieveGasPrice",
258+
     "count": 1,
259+
"lastInfo": {
260+
"gasPrice": "44436243"
261+
},
262+
     "lastOccurrence": "2023-01-27T17:13:22.93120838Z",
263+
     "time": "2023-01-27T17:13:22.93120838Z"
264+
    },
265+
{
266+
"action": "SubmitTransaction",
267+
"count": 1,
268+
  "lastInfo": {
269+
"txHash": "0x7b3a5e1ccbc0a1d5c949082bbec8ae7fe918e6621cec39478609ec7aea6103d5"
270+
},
271+
  "lastOccurrence": "2023-01-27T17:13:32.656374637Z",
272+
  "time": "2023-01-27T17:13:32.656374637Z"
273+
  }
274+
   ],
275+
  },
276+
  {
277+
   "subStatus": "Tracking",
278+
"time": "2023-01-27T17:13:33.434400219Z",
279+
  "actions": [],
280+
  },
281+
  {
282+
   "subStatus": "Stale",
283+
"time": "2023-01-27T17:15:21.222100434Z",
284+
  "actions": [
285+
    {
286+
     "action": "RetrieveGasPrice",
287+
     "count": 1,
288+
"lastInfo": {
289+
"gasPrice": "52129243"
290+
},
291+
     "lastOccurrence": "2023-01-27T17:15:22.93120838Z",
292+
     "time": "2023-01-27T17:15:22.93120838Z"
293+
    },
294+
{
295+
"action": "SubmitTransaction",
296+
"count": 1,
297+
  "lastInfo": {
298+
"txHash": "0x89995e1ccbc0a1d5c949082bbec8ae7fe918e6621cec39478609ec7a8c64abc"
299+
},
300+
  "lastOccurrence": "2023-01-27T17:15:32.656374637Z",
301+
  "time": "2023-01-27T17:15:32.656374637Z"
302+
  }
303+
   ],
304+
  },
305+
  {
306+
   "subStatus": "Tracking",
307+
"time": "2023-01-27T17:15:33.434400219Z",
308+
  "actions": [
309+
    {
310+
     "action": "ReceiveReceipt",
311+
     "count": 1,
312+
     "lastInfo": {
313+
      "protocolId": "000004897621/000000"
314+
     },
315+
     "lastOccurrence": "2023-01-27T17:15:33.94120833Z",
316+
     "time": "2023-01-27T17:15:33.94120833Z"
317+
    },
318+
    {
319+
     "action": "Confirm",
320+
     "count": 1,
321+
     "lastOccurrence": "2023-01-27T17:16:02.780275549Z",
322+
     "time": "2023-01-27T17:16:02.780275382Z"
323+
    }
324+
   ],
325+
  },
326+
  {
327+
   "subStatus": "Confirmed",
328+
   "time": "2023-01-27T17:16:03.990309381Z",
329+
   "actions": [],
330+
  }
331+
]
332+
...
333+
}
334+
```
Lines changed: 1 addition & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,2 @@
11
Operation with detail is an extension to operations that allow additional information to be encapsulated with an operation. An operation
2-
can be supplemented by a connector and that information will be returned in a `detail` field.
3-
4-
Operation with detail is a superset of an [Operation](../_includes/operation_description.md). For information about the detail provided
5-
by blockchain connectors see [Blockchain operation status](../../blockchain_operation_status.md).
2+
can be supplemented by a connector and that information will be returned in the `detail` field.

docs/reference/types/operationwithdetail.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -148,5 +148,5 @@ nav_order: 8
148148
| `created` | The time the operation was created | [`FFTime`](simpletypes#fftime) |
149149
| `updated` | The last update time of the operation | [`FFTime`](simpletypes#fftime) |
150150
| `retry` | If this operation was initiated as a retry to a previous operation, this field points to the UUID of the operation being retried | [`UUID`](simpletypes#uuid) |
151-
| `detail` | OperationWithDetail.detail | `` |
151+
| `detail` | Additional detailed information about an operation provided by the connector | `` |
152152

0 commit comments

Comments
 (0)