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
Add object reference support via ref field in protocol
Introduces the object reference and registry pattern for persisting objects across requests. The runner now includes a ref field in requests when the expected result is a reference, allowing handlers to store and reuse objects like contexts, blocks, and chains throughout the tests.
Documents the ref field and registry pattern in handler-spec.md.
Copy file name to clipboardExpand all lines: docs/handler-spec.md
+27-1Lines changed: 27 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,14 +17,16 @@ Handlers communicate with the test runner via **stdin/stdout**:
17
17
{
18
18
"id": "unique-request-id",
19
19
"method": "method_name",
20
-
"params": { /* method-specific parameters */ }
20
+
"params": { /* method-specific parameters */ },
21
+
"ref": "reference-name"
21
22
}
22
23
```
23
24
24
25
**Fields:**
25
26
-`id` (string, required): Unique identifier for this request
26
27
-`method` (string, required): The operation to perform. Each unique method must be implemented by the handler to exercise the corresponding binding API operation.
-`ref` (string, optional): Reference name for storing the returned object. Required for methods that return object references (see [Object References and Registry](#object-references-and-registry))
28
30
29
31
### Response
30
32
@@ -59,6 +61,30 @@ Handlers communicate with the test runner via **stdin/stdout**:
59
61
4.**Error Handling**: Return error responses for invalid requests or failed operations
60
62
5.**Exit Behavior**: Exit cleanly when stdin closes
61
63
64
+
## Object References and Registry
65
+
66
+
Many operations return objects (contexts, blocks, chains, etc.) that must persist across requests. The protocol uses named references and a registry pattern:
67
+
68
+
**Creating Objects**: Methods that return objects require a `ref` field in the request. The handler stores the object in a registry under that name and returns the reference name as the result.
// Handler action: Look up registry["$ctx1"], create manager, store as registry["$csm1"]
84
+
```
85
+
86
+
**Implementation**: Handlers must maintain a registry (map of reference names to object pointers) throughout their lifetime. Objects remain alive until explicitly destroyed or handler exit.
87
+
62
88
## Test Suites and Expected Responses
63
89
64
90
The conformance tests are organized into suites, each testing a specific aspect of the Bitcoin Kernel bindings. Test files are located in [`../testdata/`](../testdata/).
0 commit comments