Merge branch 'main' into fixtest

Signed-off-by: Philip Obiora <[email protected]>

README.md

@@ -65,6 +65,7 @@ Other repositories you might be interested in containing those microservice comp
 - Permissioned Ethereum connector - https://github.com/hyperledger/firefly-ethconnect
   - Private/permissioned: Hyperledger Besu / Quorum
 - Hyperledger Fabric connector - https://github.com/hyperledger/firefly-fabconnect
+- Tezos connector - https://github.com/hyperledger/firefly-tezosconnect
 - Corda connector starter: https://github.com/hyperledger/firefly-cordaconnect
   - CorDapp specific customization is required
 
@@ -245,10 +246,10 @@ Plugins: Each plugin comprises a Go shim, plus a remote agent microservice runti
   │           │ interface     │    * Standardized operations, and custom on-chain coupling
   │           └─────┬─────────┘
   │                 │
-  │                 ├─────────────────────┬───────────────────┐
-  │           ┌─────┴─────────┐   ┌───────┴───────┐   ┌───────┴────────┐
-  │           │ ethereum      │   │ fabric        │   │ corda/cordapps │
-  │           └─────┬─────────┘   └───────────────┘   └────────────────┘
+  │                 ├─────────────────────┬───────────────────┬-───────────────────┐
+  │           ┌─────┴─────────┐   ┌───────┴───────┐   ┌───────┴────────┐   ┌───────┴────────┐
+  │           │ ethereum      │   │ fabric        │   │ corda/cordapps │   │ tezos          │
+  │           └─────┬─────────┘   └───────────────┘   └────────────────┘   └────────────────┘
   │           [REST/WebSockets]
   │           ┌─────┴────────────────────┐   ┌────────────────────────┐   ┌─ 
   │           │ transaction manager [Tm] ├───┤ Connector API [ffcapi] ├───┤  Simple framework for building blockchain connectors

docs/reference/config.md

@@ -1390,6 +1390,12 @@ nav_order: 2
 |batchSize|Default read ahead to enable for subscriptions that do not explicitly configure readahead|`int`|`50`
 |batchTimeout|Default batch timeout|`int`|`50ms`
 
+## subscription.events
+
+|Key|Description|Type|Default Value|
+|---|-----------|----|-------------|
+|maxScanLength|The maximum number of events a search for historical events matching a subscription will index from the database|`int`|`1000`
+
 ## subscription.retry
 
 |Key|Description|Type|Default Value|

docs/reference/firefly_interface_format.md

@@ -95,6 +95,7 @@ The type field here is the JSON input type when making a request to FireFly to i
 
 ### Schema details
 
+<a name="schema-details"></a>
 The details field is quite important in some cases. Because the `details` field is passed to the blockchain plugin, it is used to encapsulate blockchain specific type information about a particular field. Additionally, because each blockchain plugin can add rules to the list of schema requirements above, a blockchain plugin can enforce that certain fields are always present within the `details` field. 
 
 For example, the Ethereum plugin always needs to know what Solidity type the field is. It also defines several optional fields. A full Ethereum details field may look like:

docs/reference/types/subscription.md

@@ -105,7 +105,7 @@ nav_order: 3
 | `firstEvent` | Whether your application would like to receive events from the 'oldest' event emitted by your FireFly node (from the beginning of time), or the 'newest' event (from now), or a specific event sequence. Default is 'newest' | `SubOptsFirstEvent` |
 | `readAhead` | The number of events to stream ahead to your application, while waiting for confirmation of consumption of those events. At least once delivery semantics are used in FireFly, so if your application crashes/reconnects this is the maximum number of events you would expect to be redelivered after it restarts | `uint16` |
 | `withData` | Whether message events delivered over the subscription, should be packaged with the full data of those messages in-line as part of the event JSON payload. Or if the application should make separate REST calls to download that data. May not be supported on some transports. | `bool` |
-| `batch` | Events are delivered in batches in an ordered array. The batch size is capped to the readAhead limit. The event payload is always an array even if there is a single event in the batch. Commonly used with Webhooks to allow events to be delivered and acknowledged in batches. | `bool` |
+| `batch` | Events are delivered in batches in an ordered array. The batch size is capped to the readAhead limit. The event payload is always an array even if there is a single event in the batch, allowing client-side optimizations when processing the events in a group. Available for both Webhooks and WebSockets. | `bool` |
 | `batchTimeout` | When batching is enabled, the optional timeout to send events even when the batch hasn't filled. | `string` |
 | `fastack` | Webhooks only: When true the event will be acknowledged before the webhook is invoked, allowing parallel invocations | `bool` |
 | `url` | Webhooks only: HTTP url to invoke. Can be relative if a base URL is set in the webhook plugin config | `string` |

docs/reference/types/wsstart.md

@@ -96,7 +96,7 @@ nav_order: 23
 | `firstEvent` | Whether your application would like to receive events from the 'oldest' event emitted by your FireFly node (from the beginning of time), or the 'newest' event (from now), or a specific event sequence. Default is 'newest' | `SubOptsFirstEvent` |
 | `readAhead` | The number of events to stream ahead to your application, while waiting for confirmation of consumption of those events. At least once delivery semantics are used in FireFly, so if your application crashes/reconnects this is the maximum number of events you would expect to be redelivered after it restarts | `uint16` |
 | `withData` | Whether message events delivered over the subscription, should be packaged with the full data of those messages in-line as part of the event JSON payload. Or if the application should make separate REST calls to download that data. May not be supported on some transports. | `bool` |
-| `batch` | Events are delivered in batches in an ordered array. The batch size is capped to the readAhead limit. The event payload is always an array even if there is a single event in the batch. Commonly used with Webhooks to allow events to be delivered and acknowledged in batches. | `bool` |
+| `batch` | Events are delivered in batches in an ordered array. The batch size is capped to the readAhead limit. The event payload is always an array even if there is a single event in the batch, allowing client-side optimizations when processing the events in a group. Available for both Webhooks and WebSockets. | `bool` |
 | `batchTimeout` | When batching is enabled, the optional timeout to send events even when the batch hasn't filled. | `string` |
 | `fastack` | Webhooks only: When true the event will be acknowledged before the webhook is invoked, allowing parallel invocations | `bool` |
 | `url` | Webhooks only: HTTP url to invoke. Can be relative if a base URL is set in the webhook plugin config | `string` |