Replace ThreadPool with ThreadPoolExecutor for async_req

[yonatan-genai]

Summary

The async_req=True code path uses multiprocessing.pool.ThreadPool, which
depends on POSIX named semaphores (sem_open). This fails on platforms without
/dev/shm, notably AWS Lambda, Android, and Docker containers with restricted
shared memory.

ThreadPool is only used for thread-based parallelism here, not multiprocessing.
The ThreadPoolExecutor (from concurrent.futures) is already used internally
by the async_threadpool_executor path. This change reuses it for async_req
as well, eliminating the multiprocessing dependency entirely.

A .get() alias is added to the returned Future for backward compatibility
with existing code that calls .get(timeout) (the ApplyResult API) instead
of .result(timeout) (the Future API).

Changes

• pinecone/openapi_support/api_client.py: Replace self.pool.apply_async()
  with self.threadpool_executor.submit(), remove ThreadPool property and
  multiprocessing imports
• pinecone/adapters/response_adapters.py: Update UpsertResponseTransformer
  from ApplyResult to Future

Related

• Pinecone community: https://community.pinecone.io/t/error-using-pinecone-client-at-lambda-aws/3478
• LangChain issues: Issue: Pinecone.from_documents cannot run on AWS Lambda because of multiprocessing langchain-ai/langchain#11168, pinecone: Fix multiprocessing issue in PineconeVectorStore langchain-ai/langchain#24042

---

Note

Medium Risk
Touches the async request execution path and changes the concrete return type for async_req=True; subtle behavior differences between ApplyResult.get() and Future.result() (timeouts/cancellation/exceptions) could affect callers despite the .get compatibility alias.

Overview
Async OpenAPI requests (async_req=True) are migrated off multiprocessing.pool.ThreadPool to concurrent.futures.ThreadPoolExecutor, removing the multiprocessing/POSIX semaphore dependency and improving compatibility with restricted environments (e.g., Lambda containers).

ApiClient.call_api() now returns a Future (with a .get alias to .result for backward compatibility), and UpsertResponseTransformer is updated to wrap a Future instead of an ApplyResult while keeping the same .get()-based transformation behavior.

^{Written by Cursor Bugbot for commit 159cac6. 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]

Future has no .get() method; use .result()

Medium Severity

UpsertResponseTransformer.get() calls self._future.get(timeout), but concurrent.futures.Future does not have a .get() method — its API is .result(timeout). This only works by accident because api_client.py monkey-patches future.get = future.result on the returned future. The internal UpsertResponseTransformer class should call self._future.result(timeout) directly instead of relying on the external monkey-patch, which is intended for backward compatibility of external callers.

Additional Locations (1)

• pinecone/openapi_support/api_client.py#L336-L337