lihongyuan99 54c65d8ef6

fix(sandbox): resolve the async acquire lock path off the event loop (#5760) ...

* fix(sandbox): resolve the async acquire lock path off the event loop

_discover_or_create_with_lock_async offloads every step of the acquire —
ensure_thread_dirs, the lock file, cache re-checks, backend discovery and
registration — except the one line that builds the lock path itself, which
resolves through Paths.base_dir and therefore runs a syscall on the loop.

The sibling anchor documented that as "a pre-existing blocking call in this
coroutine" and stubbed the path layer to get past it. With the resolution in
a worker thread the stub is no longer needed, so this removes it and pins the
behaviour with an anchor of its own.

* test(sandbox): word the offload anchor against the state after the stub removal

* test(sandbox): pin that the gate still catches an inline thread_dir call

The lock-path anchor only asserts execution reached the lock file, so it would
stay green if the gate stopped instrumenting the syscalls behind Path.resolve()
and the inline call were restored. Add a meta-check next to the store probe's:
call thread_dir() directly on the event loop under the same isolation and
assert BlockingError.

2026-09-24 15:19:50 +08:00

..

extension-api

feat(plugins): support manifests and static asset directories (#5685)

2026-09-23 15:40:22 +08:00

harness

fix(sandbox): resolve the async acquire lock path off the event loop (#5760)

2026-09-24 15:19:50 +08:00