Why the True Async RFC Failed: Lessons for PHP’s Asynchronous Future

Vote Rejected

In the latest PHP community update, the highly anticipated True Async RFC—intended to introduce native coroutines and async/await primitives—was decisively rejected. The vote, opened on November 20, 2025, quickly amassed overwhelming opposition.

According to the PHP internals mailing list and the RFC voting page, 20 core developers have voted: 1 in favor, 15 against, and 4 abstaining. With the deadline on December 6 and a two‑thirds majority required, the proposal was effectively doomed.

Members of the 🚀 webman技术交流 #1 group had already anticipated this outcome; Swoole founder Han Tianfeng had warned that the RFC was unlikely to pass.

An Ambitious Asynchronous Revolution

Proposed by developer Edmond Dantes, the True Async RFC sought to add native coroutines, async/await syntax, and related primitives to PHP, making concurrent programming as easy as drinking water.

The core goals were clear: enable developers to run existing synchronous code inside coroutines with minimal changes, while preserving behavior in non‑coroutine contexts, provided shared mutable memory is handled correctly.

Key features included:

Async namespace : introduces functions like spawn(), await(), suspend(), and interfaces such as Coroutine, Awaitable, FutureLike. spawn() starts a new coroutine; await() supports optional cancellation.

Cancellation mechanism : uses CancellationError (subclass of Error) for cooperative cancellation, reducing boilerplate.

Scheduler and reactor : leverages libuv’s Reactor for I/O events and a Scheduler to manage coroutine execution, with dead‑lock detection and graceful shutdown via gracefulShutdown().

Backward compatibility : no changes to existing function signatures or SAPI (FPM, CLI); extensions can integrate via the C‑API.

The RFC depended on a separate Reactor extension and targeted PHP 8.6+. It drew inspiration from Swoole, AMPHP, and Go, but emphasized “lightweight coroutines” rather than heavyweight goroutine‑style stacks.

Edmond Dantes provided a prototype on GitHub (https://github.com/true-async) demonstrating a singleton AuthService where coroutines break shared state like session IDs, yet SQL queries remain unchanged—illustrating the philosophy that concurrency challenges belong to developers, not the language.

Had it succeeded, the RFC could have turned PHP into a strong contender for read‑intensive, non‑blocking applications without relying on third‑party frameworks such as Swoole or ReactPHP.

From Expectation to Disappointment

The voting announcement was posted on November 19 by Dantes on the internals list. A key change in version 1.6 required all I/O functions to be non‑blocking, but the separate voting page sparked controversy about its placement and perceived haste.

Community feedback was intense. Bob Weinand questioned the sudden vote and suggested forming a working group. Tim Düsterhus criticized API design, noting the missing top‑level Throwable and inconsistent naming (e.g., gracefulShutdown should follow snake_case). Rob Landers warned that shared memory without explicit suspension points could lead to chaos.

Deeper disagreements centered on the design committee’s role. Daniil Gentili called the discussion “bikeshedding,” urging a single clear vision. Deleu feared low adoption of async PHP and stressed the need for seamless sync compatibility. Jakub Zelenka argued the proposal was over‑broad and should be split into smaller RFCs.

Supporters like Michał Marcin Brzuchalski voted “yes” to show overall backing for native async, and Swoole author Han Tianfeng praised Swoole’s Boost.Context‑based stackful coroutines, but their voices were drowned out by the opposition.

The final tally was a stark 15 against, 1 for, and 4 abstentions—far short of the required two‑thirds majority.

Where Does PHP’s Asynchronous Future Go?

The failure of True Async is not the end but a warning sign. It exposed pain points in the PHP community: lack of consensus, high API design thresholds, and strict backward‑compatibility constraints. While frameworks like Swoole prove async is feasible, ecosystem fragmentation hampers mainstream adoption.

Future progress may require a “small steps, fast runs” approach: first ship a Reactor extension, then gradually introduce coroutine APIs. Learning from Go’s governance model, the community could form a focused expert group to avoid the “everyone is an architect” trap and educate developers on safe concurrent memory handling.

Although the True Async RFC faded like a fleeting bloom, its prototype showed that coroutines can keep SQL queries unchanged while enabling multithreaded‑style concurrency. The seed has been planted, and PHP developers can look forward to a more mature asynchronous solution, perhaps in PHP 9.0.