Fix/fire and forget

[DebanKsahu]

Summary

• Fixes the blocking fire and forget issue by wrapping the async functions into asyncio.Task.
• Left the sync log_execution part as it is as it seems lightweight no, needless to delegate it to a thread.

Type of change

• Bug fix
• New feature
• Refactor / cleanup
• Docs only
• Tests only
• CI / tooling
• Breaking change

Test plan

• ./scripts/test-all.sh
• Verified the branch rebases cleanly on latest upstream/main.

Test coverage

I ran the Python SDK coverage test locally because this PR only changes Python-side code.

Command used:

cd sdk/python
uv run pytest --cov=agentfield --cov-report=term-missing

Result:

1661 passed, 4 skipped, 36 deselected, 27 warnings
TOTAL coverage: 81%

Before asking for review, please confirm:

• I ran tests for the surface(s) I changed locally.
• New code paths are covered by tests in this PR (no bare additions).
• If I removed code, I updated coverage-baseline.json in
  this PR only if the removal caused a legitimate regression and I
  called it out in the summary above.
• The coverage gate check is green in CI before requesting review.

Checklist

• I have read CONTRIBUTING.md (if present) and
  docs/DEVELOPMENT.md.
• Commits are signed and follow conventional-commits style.
• I have linked any related issues (Fixes feat(tests): add unit tests for vector memory handler functionality #123 / Closes test: add tests for TypeScript SDK utils (pattern, schema, httpAgents) #456).

Related issues / PRs

Fixes #622

[github-actions]

Performance

SDK	Memory	Δ	Latency	Δ	Tests	Status
Python	9.5 KB	+6%	0.31 µs	-11%	✓	✓

✓ No regressions detected

[github-actions]

📊 Coverage gate

Thresholds from .coverage-gate.toml: per-surface ≥ 84%, aggregate ≥ 85%, max per-surface regression ≤ 1.0 pp, max aggregate regression ≤ 0.50 pp.

Surface	Current	Baseline	Δ
control-plane	86.90%	87.40%	↓ -0.50 pp	🟡
sdk-go	91.90%	92.00%	↓ -0.10 pp	🟢
sdk-python	93.76%	93.73%	↑ +0.03 pp	🟢
sdk-typescript	90.42%	90.42%	→ +0.00 pp	🟢
web-ui	84.76%	84.79%	↓ -0.03 pp	🟡
aggregate	85.55%	85.75%	↓ -0.20 pp	🟡

✅ Gate passed

No surface regressed past the allowed threshold and the aggregate stayed above the floor.

[github-actions]

📐 Patch coverage gate

Threshold: 80% on lines this PR touches vs origin/main (from .coverage-gate.toml:thresholds.min_patch).

Surface	Touched lines	Patch coverage	Status
control-plane	0	—	➖ no changes
sdk-go	0	—	➖ no changes
sdk-python	22	86.00%	✅
sdk-typescript	0	—	➖ no changes
web-ui	0	—	➖ no changes

✅ Patch gate passed

Every surface whose lines were touched by this PR has patch coverage at or above the threshold.

[AbirAbbas]

Good direction — detaching the telemetry POST out of the reasoner's critical path is the right fix for #622, and the GC-safe idiom (_background_tasks.add + add_done_callback(discard)) is done correctly at all the sites. Two things holding back an approval, both inline.

Also: there are no tests for the new non-blocking behavior (the "covered by tests" box is unchecked), and this only fixes half of #622 — log_execution is still called synchronously on the event loop. Fine to scope that out, but say so in the PR/issue rather than leaving it silent. A ruff format pass would also clear the trailing-whitespace/indentation noise.

[AbirAbbas]

Detaching start/complete/error into independent tasks means the events can now hit the endpoint out of order — previously notify_call_start was awaited before the reasoner body ran, so "started" was guaranteed to post before "completed". If the control-plane telemetry orders by timestamp/status this is fine, but it's a real weakening of the prior contract — worth confirming the CP tolerates out-of-order start/complete and noting it in the PR.

[DebanKsahu]

Internally task queue follow the FIFO property so if start pushed first then it will execute first unless and await called will be executed inside the first task which leads it to sleep and task after the first task will be executed. Here the only async code inside the all notify functions is fire_and_forget_update() method which might cause issue.

I have 2 approach to this:

1. Convert fire_and_forget_update() to a task also so that start, complete and error execute in order then their fire_and_forget_update also queued in order.
2. Instead of converting the entire notify function into a task we should only convert the respective fire_and_forget_update() calls into task.

Please review these 2 approaches.

[AbirAbbas]

These background tasks are never drained on shutdown — stop() → _cleanup_async_resources() calls self.client.aclose() while notification POSTs may still be in flight, so the final complete/error event can be dropped if the reasoner returns right before teardown. Previously that terminal event was awaited, i.e. guaranteed delivered.

Suggest draining before the client closes: await asyncio.gather(*self._background_tasks, return_exceptions=True) (with a short timeout) in _cleanup_async_resources, ahead of aclose().

[DebanKsahu]

Sorry for my mistake, I will work on it in the next commits.

[DebanKsahu]

Good direction — detaching the telemetry POST out of the reasoner's critical path is the right fix for #622, and the GC-safe idiom (_background_tasks.add + add_done_callback(discard)) is done correctly at all the sites. Two things holding back an approval, both inline.

Also: there are no tests for the new non-blocking behavior (the "covered by tests" box is unchecked), and this only fixes half of #622 — log_execution is still called synchronously on the event loop. Fine to scope that out, but say so in the PR/issue rather than leaving it silent. A ruff format pass would also clear the trailing-whitespace/indentation noise.

Regarding the sync execution of log_execution, I left out because If I execute that into a separate thread then there are out of order problems occuring in the existing tests, also log_execution is lightweight so it's might don't effect the async execution. That's why I left out like this.