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: README.md
+29-2
Original file line number
Diff line number
Diff line change
@@ -29,8 +29,9 @@ are additional methods used by the token connector to guess at the contract ABI
29
29
but is the preferred method for most use cases.
30
30
31
31
To leverage this capability in a running FireFly environment, you must:
32
+
32
33
1.[Upload the token contract ABI to FireFly](https://hyperledger.github.io/firefly/tutorials/custom_contracts/ethereum.html)
33
-
as a contract interface.
34
+
as a contract interface.
34
35
2. Include the `interface` parameter when [creating the pool on FireFly](https://hyperledger.github.io/firefly/tutorials/tokens).
35
36
36
37
This will cause FireFly to parse the interface and provide ABI details
@@ -119,7 +120,7 @@ that specific token. If omitted, the approval covers all tokens.
119
120
120
121
The following APIs are not part of the fftokens standard, but are exposed under `/api/v1`:
121
122
122
-
*`GET /receipt/:id` - Get receipt for a previous request
123
+
-`GET /receipt/:id` - Get receipt for a previous request
123
124
124
125
## Running the service
125
126
@@ -179,3 +180,29 @@ $ npm run lint
179
180
# formatting
180
181
$ npm run format
181
182
```
183
+
184
+
## Blockchain retry behaviour
185
+
186
+
Most short-term outages should be handled by the blockchain connector. For example if the blockchain node returns `HTTP 429` due to rate limiting
187
+
it is the blockchain connector's responsibility to use appropriate back-off retries to attempt to make the required blockchain call successfully.
188
+
189
+
There are cases where the token connector may need to perform its own back-off retry for a blockchain action. For example if the blockchain connector
190
+
microservice has crashed and is in the process of restarting just as the token connector is trying to query an NFT token URI to enrich a token event, if
191
+
the token connector doesn't perform a retry then the event will be returned without the token URI populated.
192
+
193
+
The token connector has configurable retry behaviour for all blockchain related calls. By default the connector will perform up to 15 retries with a back-off
194
+
interval between each one. The default first retry interval is 100ms and doubles up to a maximum of 10s per retry interval. Retries are only performed where
195
+
the error returned from the REST call matches a configurable regular expression retry condition. The default retry condition is `.*ECONN.*` which ensures
196
+
retries take place for common TCP errors such as `ECONNRESET` and `ECONNREFUSED`.
197
+
198
+
The configurable retry settings are:
199
+
200
+
-`RETRY_BACKOFF_FACTOR` (default `2`)
201
+
-`RETRY_BACKOFF_LIMIT_MS` (default `10000`)
202
+
-`RETRY_BACKOFF_INITIAL_MS` (default `100`)
203
+
-`RETRY_CONDITION` (default `.*ECONN.*`)
204
+
-`RETRY_MAX_ATTEMPTS` (default `15`)
205
+
206
+
Setting `RETRY_CONDITION` to `""` disables retries. Setting `RETRY_MAX_ATTEMPTS` to `-1` causes it to retry indefinitely.
207
+
208
+
Note, the token connector will make a total of `RETRY_MAX_ATTEMPTS` + 1 calls for a given retryable call (1 original attempt and `RETRY_MAX_ATTEMPTS` retries)
0 commit comments