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
# Integration: 128 skipped (require live Conductor server)
796
+
# TOTAL: 0 failures, 0 errors
797
+
```
798
+
799
+
Integration tests skip gracefully when the Conductor server is not available (no `CONDUCTOR_SERVER_URL` / `CONDUCTOR_AUTH_KEY` / `CONDUCTOR_AUTH_SECRET` env vars). When a server is available, they run against it. **There should be NO failures in any suite.**
**Why:** Ensures we don't poll more tasks than we can fully handle (execute AND update). Both approaches achieve the same goal — async uses explicit semaphore, sync uses thread pool sizing.
645
826
646
827
---
647
828
@@ -667,6 +848,7 @@ FUNCTION execute_and_update_task(task: Task):
|`lease_extend_enabled`| Bool | false | Auto-extend task lease for long-running tasks (alternative to TaskInProgress) |
670
852
671
853
### 6.3 Environment Variable Format
672
854
@@ -1144,6 +1326,8 @@ FUNCTION reset_auth_failures():
1144
1326
auth_failures = 0
1145
1327
```
1146
1328
1329
+
**When to Reset:** Auth failures should be reset when a poll succeeds (200 response), regardless of whether tasks were returned. A successful HTTP response means authentication is working.
1330
+
1147
1331
### 9.3 Adaptive Backoff for Empty Polls
1148
1332
1149
1333
```
@@ -1440,14 +1624,23 @@ Query Params:
1440
1624
Response: List<Task>
1441
1625
```
1442
1626
1443
-
**Update Task:**
1627
+
**Update Task (v1):**
1444
1628
```
1445
1629
POST /api/tasks
1446
1630
Body: TaskResult (JSON)
1447
1631
1448
1632
Response: string (task status)
1449
1633
```
1450
1634
1635
+
**Update Task (v2) — Recommended:**
1636
+
```
1637
+
POST /api/tasks/update-v2
1638
+
Body: TaskResult (JSON)
1639
+
1640
+
Response: Task | null (next task to process for same task type)
1641
+
```
1642
+
The v2 endpoint combines update + poll: it updates the current task result and returns the next pending task (if any) for the same task type. This enables the execute-update loop optimization described in Section 5.5b.
1643
+
1451
1644
**Register Task Definition:**
1452
1645
```
1453
1646
POST /api/metadata/taskdefs
@@ -1782,7 +1975,12 @@ FUNCTION validate_and_process_order(order_id: String) → Result:
1782
1975
1783
1976
### 16.2 Long-Running Tasks (TaskInProgress)
1784
1977
1785
-
**Pattern:** Return TaskInProgress to extend lease
1978
+
**Two approaches for long-running tasks:**
1979
+
1980
+
1.**TaskInProgress (manual):** Worker returns `TaskInProgress` to re-queue itself with a callback delay. Best for tasks that need incremental progress tracking.
1981
+
2.**Lease Extension (automatic):** Set `lease_extend_enabled=true` on the worker — the SDK automatically extends the task lease periodically. Best for tasks that run continuously without needing poll-based progress.
1982
+
1983
+
**Pattern 1: TaskInProgress — Return to re-queue**
0 commit comments