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
feat(execute): Add identifiers to sent txs (#2056)
* feat(types): Add `metadata` field to transactions
* feat(rpc): Embed tx metadata into the request id for send_transaction
* feat(pytest/execute): Add transaction metadata to all transactions
* docs: Add tx id documentation
* fix: tox
When executing tests on remote networks, all transactions include metadata that helps with debugging and monitoring. This metadata is embedded in the RPC request ID and includes:
38
+
39
+
-**Test identification**: Each transaction is tagged with the specific test being executed
40
+
-**Execution phase**: Transactions are categorized as setup, testing, or cleanup
41
+
-**Action tracking**: Specific actions like contract deployment, funding, or refunding are tracked
42
+
-**Target identification**: The account or contract being targeted is labeled
43
+
44
+
This metadata is particularly useful when debugging test failures on live networks, as it allows you to correlate blockchain transactions with specific test operations and phases.
45
+
46
+
See [Transaction Metadata](./transaction_metadata.md) for details.
47
+
35
48
## `execute` Command Test Execution
36
49
37
50
The `execute remote` and `execute hive` commands first creates a random sender account from which all required test accounts will be deployed and funded, and this account is funded by sweeping (by default) this "seed" account.
The `execute` plugin automatically adds metadata to all transactions it sends to the network. This feature was introduced to improve debugging, monitoring, and transaction tracking capabilities.
4
+
5
+
## Overview
6
+
7
+
Transaction metadata provides context about each transaction sent during test execution, making it easier to:
8
+
9
+
- Debug test failures by correlating blockchain transactions with test operations
10
+
- Monitor test execution patterns and performance
11
+
- Track transaction flow across different phases of test execution
12
+
- Identify which transactions belong to which tests and phases
13
+
14
+
## Metadata Structure
15
+
16
+
Each transaction includes a `TransactionTestMetadata` object with the following fields:
17
+
18
+
| Field | Type | Description |
19
+
|-------|------|-------------|
20
+
|`testId`|`str`| The unique identifier of the test being executed (pytest node ID) |
21
+
|`phase`|`str`| The execution phase: `setup`, `testing`, or `cleanup`|
22
+
|`action`|`str`| The specific action being performed (e.g., `deploy_contract`, `fund_eoa`) |
23
+
|`target`|`str`| The label of the account or contract being targeted |
24
+
|`txIndex`|`int`| The index of the transaction within its phase |
-**`fund_eoa`**: Funding EOAs with initial balances
34
+
-**`eoa_storage_set`**: Setting storage values for EOAs
35
+
-**`fund_address`**: Funding specific addresses
36
+
37
+
### Testing Phase (`testing`)
38
+
39
+
The actual test transactions defined by the test:
40
+
41
+
- User-defined test transactions
42
+
- Blob testing transactions
43
+
44
+
### Cleanup Phase (`cleanup`)
45
+
46
+
Transactions that clean up after the test:
47
+
48
+
-**`refund_from_eoa`**: Refunding EOAs back to the sender account
49
+
50
+
## Example Metadata
51
+
52
+
```json
53
+
{
54
+
"testId": "tests/example_test.py::test_example",
55
+
"phase": "setup",
56
+
"action": "deploy_contract",
57
+
"target": "contract_label",
58
+
"txIndex": 0
59
+
}
60
+
```
61
+
62
+
## Debugging Test Failures
63
+
64
+
When a test fails on a remote network, you can use the transaction metadata to:
65
+
66
+
1. Identify which transactions belong to the failing test
67
+
2. Determine which phase of execution failed
68
+
3. Correlate blockchain transactions with specific test operations
69
+
70
+
The ID will normally be printed in the client logs when execute is running tests against the client, but the logging level might need to be increased for some of the clients (`--sim.loglevel` when running with hive).
71
+
72
+
## Technical Notes
73
+
74
+
- Metadata is automatically handled by the execute plugin
75
+
- No additional configuration is required
76
+
- Metadata is embedded in RPC requests without affecting transaction execution
77
+
- The feature is backward compatible and doesn't change test behavior
0 commit comments