A single line in php.ini currently decides whether developers see their own bugs or not: error_reporting=0. That exact default was the reason beta versions and RC2 of PHP 8.6 silently swallowed all warnings and notices inside Fibers. On October 8, 2026, PHP 8.6 RC3 was released — the second Release Candidate of the upcoming major version — clearing out that problem along with four other, partly subtle bugs.
One interesting wrinkle in the roadmap: RC1 was skipped entirely, so RC3 is actually only the second Release Candidate ever published. For PHP developers, web-dev teams, and DevOps engineers preparing their infrastructure for the new version, this article offers a compact, fact-based overview of all the changes.
Table of Contents
Key Takeaways
- PHP 8.6 RC3 was released on October 8, 2026, and fixes a critical Fiber bug that suppressed warnings and notices whenever no php.ini sets an error_reporting value — affects Docker default images and
php -n. - hrtime() measured about 4 percent too fast on some systems during the betas, because the clock source was switched from CLOCK_MONOTONIC to CLOCK_MONOTONIC_RAW; RC3 reverts that change.
- array_map() incorrectly threw TypeErrors under
strict_types=1in RC2 due to a new, untested code path — disabled again for strict_types files in RC3. - The OPcache optimizer incorrectly folded
$cond ? -0.0 : 0.0into a single constant, ignoring the condition entirely — a bug that mostly shows up in production environments with OPcache enabled. - PHP’s built-in web server has leaked a file descriptor on every HEAD request to a static file since PHP 8.2 — fixed in RC3.
- The final date for General Availability of PHP 8.6.0 is November 19, 2026.
What is PHP 8.6 RC3, and why was RC1 skipped?
PHP 8.6 RC3 is the second published Release Candidate of the upcoming 8.6.0 version. According to the official php.internals mailing list and reporting from phpnews.net and php.watch, RC1 was skipped during the development process — RC2 was effectively the first publicly released candidate, with RC3 following as the second.
Release Candidates mark the phase where no new features are added anymore. If you’re generally interested in release cycles of modern languages, our article on Node.js 27 and its new release cycle offers a good point of comparison. It’s exclusively about bug fixes, stability, and polish ahead of the final release. That’s exactly what RC3’s scope reflects: every change is a bugfix, and none of them shifts the behavior of PHP 8.6’s new language features.
The roadmap to the final version of PHP 8.6
The schedule for the remaining Release Candidates and the final version is already set. The table below summarizes the dates, consistently confirmed by both phpnews.net and php.watch:
| Milestone | Date |
|---|---|
| RC3 | October 8, 2026 |
| RC4 | October 22, 2026 |
| RC5 | November 5, 2026 |
| General Availability (PHP 8.6.0 final) | November 19, 2026 |
That leaves two more Release Candidates between RC3 and the final release. DevOps teams preparing staging environments for PHP 8.6 should keep this roadmap in mind, since every additional RC could bring further regression fixes.
The most important fixes in PHP 8.6 RC3
The core of PHP 8.6 RC3 consists of five clearly documented bugfixes, each touching a different part of the ecosystem — from asynchronous code through performance measurement to numerics.
Fiber bug: error_reporting=0 suppressed warnings
The most severe fix concerns Fibers, PHP’s mechanism for cooperative multitasking that underpins asynchronous libraries like Revolt or AMPHP. In the beta versions and in RC2, newly created Fibers started with error_reporting=0 whenever no php.ini had set an explicit value for that setting. That’s exactly the state in the official PHP Docker images and with every php -n invocation.
The consequence: every warning and notice raised inside a Fiber disappeared silently. A developer hunting a bug in asynchronous code would have seen no error message at all inside a Fiber context — a classic case of “works locally, stays silent in production.” Gina Peter Banyard fixed the issue under GH-23921. For any team running Fiber-based libraries in production, this fix alone is reason enough to test against RC3 instead of RC2.
hrtime() ran too fast in the betas
A second, particularly curious bug affected the hrtime() function, used in PHP for high-precision time measurement. In the 8.6 betas, the underlying system clock was switched from CLOCK_MONOTONIC to CLOCK_MONOTONIC_RAW. On some systems this caused measurably too-fast time values.
Nicolas Grekas documented the problem concretely: during a sleep(1) under WSL2, the actual wait time measured 1.000072 seconds, while hrtime() reported 1.038898 seconds — a deviation of roughly 4 percent. For benchmarking tools, rate limiters, or performance monitoring, this would have been a silent but consequential bug. PHP 8.6 RC3 reverts to the proven CLOCK_MONOTONIC source, as already used in PHP 8.5.
array_map() and strict_types: the TypeError trap
With RC2, array_map() had gained a new, faster internal code path that, in files with strict_types=1, type-checked the callback’s arguments. The problem: array_map() has historically never performed that check. Existing code that ran fine under PHP 8.5 suddenly threw TypeErrors in RC2.
“An optimization path that introduces new, previously never-checked behavior is particularly risky during a release phase with no new features.”
Tim Düsterhus disabled this path again for strict_types=1 contexts. For developers, this means: code using array_map() with strict types now behaves in RC3 the same way it did in PHP 8.5.
OPcache optimizer and the sign of zero
A particularly hard-to-spot bug lived in the OPcache optimizer. It incorrectly folded expressions of the form $cond ? -0.0 : 0.0 into a single constant — ignoring the actual condition entirely. In floating-point arithmetic, the sign of zero matters: 1.0 / $zero yields either INF or -INF depending on the sign of $zero.
What makes this bug especially dangerous is where it tends to show up: local development environments frequently run without OPcache enabled, while production systems almost always have it on. A bug like this often only surfaces live — right where it’s most expensive.
File descriptor leak in the built-in web server
The fourth fix concerns the built-in PHP web server (php -S), used by many teams for local development and simple test environments. Every HEAD request to a static file leaked a file descriptor. A monitoring probe sending a HEAD request every 40 seconds could exhaust the server’s available file descriptors after roughly 11 hours — leaving it unable to accept further connections.
This bug has existed since PHP 8.2 and was only discovered and fixed now, during RC3 preparation. For teams using the built-in server for health checks or CI pipelines with regular probes, this is a meaningful stability fix.
More improvements: PDO, Intl, and OpenSSL
Beyond the five main fixes, PHP 8.6 RC3 includes a number of smaller but practically relevant corrections:
- PDO:
PDOStatement::execute()used to still expose the old result after a failed execution — now corrected.setFetchMode()now applies changes atomically. A use-after-free bug when calling__toString()on a bound parameter was also closed. - PDO_DBLIB: errors from
beginTransaction(),commit(),rollBack(), andlastInsertId()are now correctly reported instead of being swallowed. - Intl/Grapheme: several fixes around the Grapheme and Intl extensions improve correctness when processing multilingual text.
- OpenSSL:
openssl_sign()now uses OpenSSL’s standard salt instead of the previous maximum value for RSA-PSS signatures — a detail that improves interoperability with other systems.
Individually small, these changes add up to a notably more robust database and cryptography layer for the final release.
Background: what else PHP 8.6 brings
While RC3 itself contains only bugfixes, it’s worth looking at the bigger, already-frozen changes coming with PHP 8.6 overall for context. These include partial function application with ? as an argument placeholder, a new clamp() function, the TimeDuration class, readonly properties with default values, a new IoPoll API, and a URI builder.
Relevant for security teams: PHP 8.6 changes several session defaults. session.use_strict_mode is set to 1, session.cookie_httponly is also set to 1 — meaning JavaScript can no longer read the session cookie. Additionally, session.cookie_samesite switches to 'Lax'. These defaults are already frozen and not part of RC3’s changes themselves, but should be factored into migration planning.
What does PHP 8.6 RC3 mean for developers and DevOps teams?
For teams that have already tested against the 8.6 betas or RC2, the key action item is clear: re-test, especially if the application uses Fibers, hrtime()-based measurements, array_map() with strict_types=1, or floating-point sign-dependent calculations.
Concrete recommendations:
- Review async code: anyone using Revolt, AMPHP, or custom Fiber-based solutions should confirm warnings and notices are visible again in test environments.
- Validate performance measurements: anyone using
hrtime()for benchmarks or rate limiting should re-check values after updating to RC3. - Test CI pipelines with strict_types: existing tests that threw TypeErrors on
array_map()in RC2 should be re-run under RC3. - Enable OPcache in staging: since the zero-sign bug only occurs with OPcache active, it should also be enabled in test environments to realistically mirror production conditions.
- Review monitoring intervals: anyone running the built-in PHP server with regular health checks benefits directly from the file-descriptor-leak fix.
Conclusion
PHP 8.6 RC3 is a textbook example of what Release Candidates are for: finding and fixing bugs before they reach millions of production environments. The Fiber bug around error_reporting=0 alone had the potential to cause silent failures in every modern asynchronous PHP project. Combined with the hrtime() correction, the array_map() TypeError-trap fix, the OPcache zero-sign fix, and the closed file-descriptor leak, RC3 marks a clear step toward stability.
Teams should act now: update staging environments to PHP 8.6 RC3, re-run existing test suites, and specifically review Fiber-based code as well as floating-point logic. Before the final release on November 19, 2026, RC4 (October 22) and RC5 (November 5) still offer two more opportunities to report remaining issues — thorough early testing of PHP 8.6 RC3 pays off for any team planning a smooth upgrade.
Sources
- phpnews.net: https://phpnews.net/php-8-6-rc3
- php.watch: https://php.watch/versions/8.6/releases/8.6.0RC3
- php.internals mailing list: https://news-web.php.net/php.internals/132836
