zc2 0.0.13

P2P compute broker with credit-based billing, WAL, and broker mesh support
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105

# Test 30s execution flow (TUI + task pile + async)

This describes how to run a **single 30-second execution** so you have time to attach with `zc attach` and watch the execution flow in the terminal (task pile, transactions, worker assignment, price/owner/pid/ip).

## One-command E2E script

From the repo root, with `ZAKURO_API_KEY` set:

```bash
./scripts/e2e_fibonacci_broadcast_30s.sh
```

The script starts the broker and a fibonacci worker, then tells you to attach in another terminal. After a short delay it triggers one ~30s task so you can see the pile and execution in the attach TUI. On exit (or Ctrl+C) it stops the broker and worker.

## Plan

1. **Worker**: Fibonacci worker accepts optional `"sleep": N` (seconds) in the request body; it sleeps N seconds before computing and responding. One request can thus last ~30s.

2. **Broker**: Run the broker (with or without built-in TUI). Request handling is on separate threads, so a long /execute does not block /health or /stats.

3. **Attach**: In another terminal, run `zc attach localhost:9000` (with `ZAKURO_API_KEY` set). Stats are fetched in a background thread so the TUI stays responsive.

4. **Trigger**: Send one POST /execute with `{"n": 4, "sleep": 30}` via the broker. You’ll see the task in the TUI; when a worker is assigned and running, the execution lasts 30s so you can watch the flow.

## Steps (three terminals)

### Terminal 1 – Broker

```bash
# Option A: Broker with built-in TUI (local dashboard)
zc -t broker 9000

# Option B: Broker in foreground (no TUI, verbose logs)
zc broker 0.0.0.0 9000
```

Leave this running.

### Terminal 2 – Worker

```bash
cd /path/to/zak-zc
export ZAKURO_WORKER_DIR=/path/to/zak-zakuro   # if you use zak-zakuro
# Or run the Fibonacci worker directly (supports sleep for this test):
python3 scripts/fibonacci_worker.py --port 3960
```

Leave this running.

### Terminal 3 – Attach, then trigger 30s execution

1. **Attach** (do this first so the TUI is ready):

   ```bash
   export ZAKURO_API_KEY=zk_<your_user_id>_<secret>   # your key
   zc attach localhost:9000
   ```

2. **In a fourth terminal** (or after attaching, use another tab), **trigger one 30s request**:

   ```bash
   export ZAKURO_API_KEY=zk_<your_user_id>_<secret>
   curl -s -X POST http://localhost:9000/execute \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer $ZAKURO_API_KEY" \
     -H "X-Zakuro-Requirements: {\"strategy\":\"round_robin\",\"estimated_duration_secs\":30}" \
     -d '{"n": 4, "sleep": 30}'
   ```

   The request will take ~30 seconds. In the attach TUI you should see (depending on timing):

   - **Task pile**: If P2P is used and the task is offered to peers, an offer line.
   - **Transactions**: A row for the execution with worker name, owner, price, pid@ip once the worker responds (after the 30s sleep).

3. **Optional**: Use the helper script to trigger the 30s request:

   ```bash
   python3 scripts/trigger_30s_execution.py
   ```

## Publish 10 fibonacci jobs

To verify that workers are assigned and return correct results for multiple jobs:

1. Start the broker and fibonacci worker (same as above, or use `./scripts/e2e_fibonacci_broadcast_30s.sh` and leave them running; you can skip attaching).
2. In another terminal, run:

   ```bash
   export ZAKURO_API_KEY=zk_<your_user_id>_<secret>
   export ZAKURO_API_URL=http://localhost:9000   # optional, default
   python3 scripts/trigger_10_fibonacci_jobs.py
   ```

   The script sends 10 `POST /execute` requests with `{"n": 4}` (fib(4)=3). Each job is routed to a worker; the script checks that the response contains `result: 3` and prints a line per job. If all 10 succeed, workers were assigned and returned the expected calculation.

## What you should see

- **Attach TUI**: Task pile (if offers are used), transactions table with columns TIME, FROM, WORKER, OWNER, PRICE, COST, MS. For the 30s run, duration will be ~30000 ms and worker identity (pid, ip) appears when the worker sends `X-Zakuro-Pid` / `X-Zakuro-IP`.
- **Broker (if verbose)**: Console log line for the transaction when it completes.
- **Async behaviour**: While the 30s request is in flight, the attach TUI keeps updating (stats fetch in background); the broker can still serve /health and /stats on other threads.

## Notes

- If you don’t use P2P, there is no “task pile” offer; the task is assigned locally and you’ll see the transaction when it completes.
- For a local worker, `owner_id` and price come from the broker config and worker registration; `pid` and `ip` come from the worker’s response headers (Fibonacci worker sets them).