You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/architecture/blockchain_connector_framework.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -146,7 +146,7 @@ A reference implementation is provided that:
146
146
The reference implementation is available [here](https://github.com/hyperledger/firefly-transaction-manager/blob/main/pkg/policyengines/simple/simple_policy_engine.go)
147
147
148
148
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)
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.
23
23
24
24
## Blockchain Operation Status
25
25
@@ -29,41 +29,43 @@ FireFly 1.2 introduced the concept of sub-status types that allow a blockchain c
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.
33
33
34
-
### Example
34
+
### Blockchain Operation Example
35
35
36
36
```json
37
37
{
38
38
"id": "04a8b0c4-03c2-4935-85a1-87d17cddc20a",
39
+
"created": "2022-05-16T01:23:15Z",
39
40
"namespace": "ns1",
40
41
"tx": "99543134-769b-42a8-8be4-a5f8873f969d",
41
42
"type": "blockchain_invoke",
42
43
"status": "Succeeded",
43
44
"plugin": "ethereum",
44
45
"input": {
45
-
"id": "80d89712-57f3-48fe-b085-a8cba6e0667d"
46
+
// Input used to initiate the blockchain operation
// Full blockchain operation information, including sub-status
54
+
// transitions that took place for the operation to succeed.
52
55
}
53
-
"created": "2022-05-16T01:23:15Z"
54
56
}
55
57
```
56
58
57
-
## Status Structure
59
+
## Detail Status Structure
58
60
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:
60
62
61
63
-**history** an ordered list of status changes that have taken place during processing of the transaction
62
64
-**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.
63
65
64
66
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`.
65
67
66
-
### Example
68
+
### History Example
67
69
68
70
```json
69
71
{
@@ -73,7 +75,7 @@ The `history` field is designed to record an ordered list of sub-status changes
73
75
"history": [
74
76
{
75
77
"subStatus": "Received",
76
-
"time": "2023-01-27T17:11:41.122965803Z"
78
+
"time": "2023-01-27T17:11:41.122965803Z",
77
79
"actions": [
78
80
{
79
81
"action": "AssignNonce",
@@ -106,7 +108,7 @@ The `history` field is designed to record an ordered list of sub-status changes
106
108
},
107
109
{
108
110
"subStatus": "Tracking",
109
-
"time": "2023-01-27T17:11:41.222400219Z"
111
+
"time": "2023-01-27T17:11:41.222400219Z",
110
112
"actions": [
111
113
{
112
114
"action": "ReceiveReceipt",
@@ -137,7 +139,7 @@ The `history` field is designed to record an ordered list of sub-status changes
137
139
138
140
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.
139
141
140
-
### Example
142
+
### History Summary Example
141
143
142
144
```json
143
145
{
@@ -194,3 +196,139 @@ Because the `history` field is a FIFO structure describing the N most recent sub
194
196
]
195
197
}
196
198
```
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.
Copy file name to clipboardExpand all lines: docs/reference/types/operationwithdetail.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -148,5 +148,5 @@ nav_order: 8
148
148
|`created`| The time the operation was created |[`FFTime`](simpletypes#fftime)|
149
149
|`updated`| The last update time of the operation |[`FFTime`](simpletypes#fftime)|
150
150
|`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| `` |
0 commit comments