fix(crew): add missing drain_writes call in akickoff finally block

[wishhyt]

Summary

• The synchronous kickoff() correctly calls self._memory.drain_writes() in its finally block to ensure all background memory saves complete before returning.
• The async akickoff() was missing this call, so background memory writes could be silently lost when using the async entry point.

Changes

Added the same drain_writes() call to akickoff()'s finally block.

Test plan

Run a crew with memory enabled via akickoff() and verify memory records are persisted

---

Note

Low Risk
Low risk: adds a guarded drain_writes() call in an async finally block to prevent losing queued memory writes, with minimal behavioral impact beyond waiting for persistence.

Overview
Native async Crew.akickoff() now mirrors the sync kickoff() cleanup behavior by calling self._memory.drain_writes() (when supported) in its finally block before clear_files()/context detach.

This prevents background memory saves from being dropped when using the native async entrypoint.

^{Written by Cursor Bugbot for commit be48692. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Blocking call in async method stalls event loop

Medium Severity

drain_writes() is a synchronous method that calls future.result() on concurrent.futures.Future objects, which blocks the calling thread. Invoking it directly inside the async def akickoff() method blocks the event loop, preventing all other coroutines from making progress until every pending memory save completes. This is particularly impactful when multiple crews run concurrently via asyncio.gather() or similar patterns. The call needs to be offloaded (e.g., via asyncio.to_thread) to avoid starving the event loop.

 

[greysonlalonde]

Duplicate of #4768. Closing.