---

Vix.cpp v2.6.3

Vix.cpp v2.6.3 is a stability and engineering-discipline release.

It does not try to introduce a large new product surface like v2.6.0. Instead, it focuses on making the existing Vix.cpp runtime, CLI, Core module, tests, benchmarks, and CI workflows more reliable.

This release strengthens several areas that matter for a serious C++ application platform:

• safer project execution through vix run
• better long-running test visibility through vix tests
• more deterministic Core shutdown behavior
• stronger HTTP session edge-case handling
• official Core benchmark baselines
• broader sanitizer-ready module testing
• better static analysis scope
• deterministic threadpool cancellation behavior
• improved JSON module coverage
• stricter CI without blocking on third-party or irrelevant files

The focus of v2.6.3 is simple:

stabilize the runtime
measure performance
strengthen CI
make failures easier to trust

Release focus

Vix.cpp v2.6.3 focuses on reliability.

Previous v2.6 releases expanded the platform with AI workflows, vix.app, game tooling, Vue integration, and stronger developer workflows. v2.6.3 takes that foundation and hardens it.

The release improves how Vix behaves when projects are larger, tests are slower, shutdown paths are concurrent, benchmarks are enabled, sanitizer builds are active, and CI needs to distinguish real project problems from false positives.

This is important because Vix.cpp is not only a library. It is becoming a full native application workflow for C++.

That means the project must care about more than APIs.

It must care about:

• how applications start
• how they stop
• how tests run
• how failures are diagnosed
• how benchmarks are stored
• how CI decides what is blocking
• how modules behave outside the umbrella build
• how release confidence is built

Vix.cpp v2.6.3 is about that confidence.

Registry and publish stability

This release fixes several issues around vix publish and registry state handling.

Publishing now prepares and normalizes the local registry index internally before publishing. That means the publish workflow is less dependent on stale local state.

The local registry state is refreshed more defensively by fetching origin, resetting to origin/main, and cleaning untracked registry entry files before checking existing package versions.

This matters because package publishing should not fail because of an old or dirty local registry checkout.

v2.6.3 also improves diagnostics when a package version already exists in the registry.

The goal is to make registry failures clearer and less surprising.

JSON module fixes and coverage

The JSON module receives an important JPath parsing fix.

Paths after bracket segments now parse correctly, including shapes such as:

users[0].email
["complex.key"].value

This is a small-looking fix, but it matters because JPath is often used in real data access paths where arrays, object keys, and nested properties are mixed.

The JSON module also receives stronger dedicated CMake targets for examples, tests, and benchmarks.

Documentation was expanded for:

• builders
• parsing
• dumping
• safe access
• JPath
• Simple payloads
• tests
• benchmarks
• useful links

The release also adds benchmark result snapshots for JSON construction, conversion, dumping, parsing, JPath, and Simple payloads.

This improves the JSON module as both a user-facing API and a measurable runtime component.

vix run improvements

vix run receives several important fixes around executable resolution.

CMake projects do not always produce binaries with the same name as the project directory. v2.6.3 fixes executable resolution for those projects.

It also improves diagnostics when a build produces multiple runnable executables.

This makes vix run more reliable in real projects where the build output is not trivial.

The project watch mode also now resolves runnable executables generically instead of assuming the binary name matches the project folder.

That is an important workflow improvement because development sessions should follow the actual build output, not naming assumptions.

This release also fixes a CLI run preset selection false positive by ensuring empty preset lists are handled before accessing the first preset.

Better compiler diagnostics

v2.6.3 improves compiler diagnostics for template errors originating in system headers.

When possible, Vix can re-anchor those errors to the relevant project instantiation location.

This matters because C++ template failures often appear deep inside standard library or third-party headers. The real mistake is usually in user code, but the compiler output may not make that obvious at first glance.

Vix does not hide the compiler.

It tries to make the useful part of the compiler output easier to reach.

vix tests progress and interruption handling

vix tests receives improvements for long CTest runs.

The live progress output now shows:

completed
total
running
elapsed time

This makes long test sessions easier to follow.

The release also fixes interruption handling so Ctrl+C is reported as a user interruption instead of being treated as a test failure.

That distinction matters.

A user interruption is not the same thing as a broken test suite.

HTTP session hardening

Vix Core receives several HTTP session fixes for edge cases.

The release improves parsing and error-response behavior for:

• malformed requests
• invalid content lengths
• oversized payloads
• unexpected EOF bodies

It also fixes HTTP keep-alive shutdown behavior for case-insensitive Connection: close handling.

This kind of work is not always visible in simple examples, but it is critical for real servers.

HTTP servers must behave correctly when clients send bad input, partial input, or protocol edge cases.

v2.6.3 makes that layer more robust.

Core lifecycle and shutdown semantics

One of the most important parts of v2.6.3 is the work on Core lifecycle behavior.

This release strengthens shutdown semantics across:

• App
• HTTPServer
• RuntimeExecutor
• async TCP services

App::close() is now terminal, idempotent, and safe before or after listen().

App::wait() now ensures signal-stop paths close the running server instead of only exiting the wait loop.

App::listen() prevents closed app instances from being restarted accidentally.

The HTTP server shutdown ordering was improved so the accept loop can drain before the async I/O context is stopped.

The TCP listener is destroyed before shutting down the async context.

Readiness signaling now marks the server as ready only after the accept loop has started.

Metrics-thread shutdown races were also fixed by serializing metrics-thread creation with shutdown joining.

This is deep infrastructure work.

The result is a Core module that behaves more predictably under fast lifecycle tests, shutdown races, signal stops, and sanitizer instrumentation.

Async TCP shutdown fixes

The async TCP layer also receives important shutdown fixes.

Async TCP stream close behavior now cancels pending operations, shuts down the socket, and closes it safely.

Async TCP listener close behavior now cancels and closes the acceptor on the Asio executor.

Pending accepts keep the acceptor alive until completion handlers finish.

Async shutdown behavior was improved so pending Asio operations can complete and resume awaiting coroutines cleanly.

The async scheduler shutdown path was also fixed so pending coroutine handles are not silently destroyed before completion paths can run.

This work matters because async shutdown bugs can be intermittent and difficult to reproduce.

They may pass in normal runs and fail only under sanitizer builds, Valgrind, slow machines, or CI timing conditions.

v2.6.3 reduces those races.

Runtime executor fixes

The runtime executor receives shutdown and idle-detection fixes.

Pending posted tasks are now drained before workers are stopped.

Idle detection now tracks accepted in-flight tasks before they begin execution.

This avoids cases where the runtime could appear idle while accepted work had not started yet.

The runtime worker shutdown behavior was also fixed when yielding tasks are still being rescheduled.

Together, these changes make the runtime executor more reliable under concurrent workloads, shutdown paths, and tests that depend on deterministic completion.

Official Core benchmark suite

v2.6.3 adds the official Vix Core benchmark suite.

The suite covers both low-level runtime paths and higher-level application behavior:

runtime.task
runtime.queue
runtime.scheduler
runtime.worker

executor.submit
executor.post
executor.metrics

router.match
router.registration

http.request
http.response

session.fake_transport

app.route_registration
app.group_registration

The release also adds shared benchmark utilities for:

• median time
• mean time
• operations per second
• warmup iterations
• measured samples
• JSON report generation

This gives Vix Core a repeatable benchmark workflow instead of relying on manual impressions.

Official v2.6.3 benchmark baseline

Vix.cpp v2.6.3 adds the official Core v2.6.3 Release benchmark baseline.

The baseline was generated on:

OS: Linux
Arch: x86_64
Compiler: GCC 13.3.0
Build type: Release

The baseline is stored under:

modules/core/benchmarks/baselines/v2.6.3/

The release also adds:

scripts/run_core_benchmarks.sh
scripts/compare_core_benchmarks.py

The run script generates versioned benchmark JSON reports.

The comparison script compares current benchmark results against a baseline using configurable warning and failure thresholds.

By default, benchmark comparison uses:

median_ops_per_sec

Higher is better.

The default thresholds are:

WARN = -5%
FAIL = -10%

This turns performance into a tracked engineering signal.

Performance should not be based on feelings.

It should be measured, stored, compared, and protected.

Benchmark build rules

v2.6.3 documents an important benchmark rule.

Official performance numbers must be generated from Release builds, not dev or debug builds.

dev/debug = compile, test, debug
release   = measure performance

This rule is important because debug builds are useful for development but not for official performance measurement.

The Core module README was updated with benchmark workflow documentation and a link to the official v2.6.3 benchmark baseline article.

Benchmark binaries are now grouped under:

build-release/benchmarks/core

when Core benchmarks are enabled with:

-DVIX_CORE_BUILD_BENCHMARKS=ON

Core benchmark stability

v2.6.3 also fixes and stabilizes Core benchmark workloads so long-running benchmark targets do not block full benchmark runs.

Valgrind CI was updated to avoid running benchmark binaries as normal memory-test executables.

This distinction is important.

Benchmarks and memory tests serve different purposes.

Benchmark binaries are performance tools. They should not accidentally become blocking memory-test targets in strict CI.

Core test layout

The Core test layout was strengthened with dedicated test groups for:

• HTTP
• router
• session
• server
• runtime
• executor
• config
• app behavior

Network-based tests now use isolated ports, timeouts, and serial execution where required.

This makes the Core test suite more explicit and less fragile.

v2.6.3 also adds broad HTTP session test coverage for:

• transports
• parsed request heads
• constructors
• GET requests
• bodies
• errors
• keep-alive
• WAF behavior
• TLS sessions

HTTP server tests were expanded for:

• TLS config
• constructors
• router integration
• threading
• shutdown
• run validation

Runtime tests were expanded for:

• budgets
• tasks
• mailboxes
• run queues
• supervisors
• workers
• schedulers
• runtime config
• lifecycle behavior

Executor tests were expanded for:

• metrics
• task options
• construction
• lifecycle
• submit/post behavior
• shutdown

Config tests were expanded for:

• defaults
• environment loading
• set/get behavior
• typed accessors
• database settings
• WAF settings
• TLS settings
• logging settings
• reload behavior
• copy/move behavior

App tests were expanded for:

• constructors
• config access
• dev mode
• templates
• routes
• groups
• middleware
• protected routes
• static directories
• static hooks
• lifecycle behavior
• module initialization
• stdout configuration

This is one of the most important signs that v2.6.3 is a hardening release.

Strict Core CI

v2.6.3 adds strict Core CI coverage for:

• debug/runtime builds
• sanitizer builds
• Valgrind memory checks
• static analysis
• benchmark builds
• package export validation

Core sanitizer coverage was improved for:

• lifecycle
• shutdown
• executor
• session
• server
• app behavior

Valgrind timeouts were increased for slower runtime and lifecycle tests under instrumentation.

Strict CI is not only about running more tools.

It is about running the right tools on the right targets.

SECURITY_CI improvements

The release makes several important changes to SECURITY_CI.

The CI now builds and runs module-level tests instead of relying only on root-level test discovery.

It enables tests for modules that keep their tests inside each module directory.

It also runs broad module tests with ASan/UBSan enabled.

This expands sanitizer-ready module test coverage across many modules, including:

async
cache
conversion
crypto
env
error
fs
game
io
json
kv
log
middleware
os
path
p2p
process
sync
template
tests
threadpool
time
validation
webrpc
websocket
agent

This is a major improvement for umbrella-level confidence.

It means more modules are tested in the way they are actually organized.

Static analysis scope fixes

v2.6.3 fixes static-analysis scope so CI focuses on project source files instead of unrelated files.

Third-party code, generated files, examples, benchmarks, and tests are no longer treated as blocking project source analysis.

This matters because strict static analysis is only useful when it is correctly scoped.

The release fixes cppcheck CI failures caused by analyzing vendored Asio tests and optional backend files outside the configured build profile.

Blocking cppcheck analysis now runs on module implementation sources only.

Style-only cppcheck findings are still reported, but separately from blocking warnings, performance, and portability checks.

Clang-tidy analysis now uses configured source files from the CMake compilation database.

Optional SDL backend files are not analyzed when SDL support is disabled.

This keeps CI strict without turning irrelevant files into release blockers.

Sanitizer linking across modules

v2.6.3 fixes sanitizer linking for module tests across a broad set of modules.

This includes modules such as:

async
cache
crypto
game
json
kv
middleware
p2p
sync
template
tests
time
webrpc
websocket
agent
threadpool
path
fs
io
log
os
process
error
env

The release also updates module test CMake files to consistently attach sanitizer compile and link options to test executables.

This is important because sanitizer-enabled static libraries often require the final test executables to link with the required ASan/UBSan runtime flags.

Without that, tests can fail at link time instead of testing the real code.

Threadpool determinism

The threadpool module receives several deterministic behavior fixes.

Future handling for pre-cancelled and queued-cancelled tasks now resolves deterministically instead of hanging.

Task handle cancellation paths now report cancellation through the associated future.

Threadpool tests that assumed asynchronous work completed immediately after posting were fixed.

ExecutorTest now waits for posted threadpool work to complete before checking shared state.

ShutdownTest behavior expectations were fixed for the allow_after_stop submission policy.

These changes matter because threadpool tests must not depend on timing luck.

Concurrency tests should prove behavior, not race the scheduler.

Smaller module fixes

v2.6.3 also includes several focused module fixes.

The game registry clear test was fixed to avoid reading a system object after Registry::clear() destroys owned systems.

The time module smoke test was fixed to avoid signed integer overflow detected by UBSan.

The validation module test linking was fixed by avoiding a single GoogleTest binary for plain test files that each define their own main.

These fixes are small individually, but together they improve the reliability of broad module testing.

Highlights

• Fixed vix publish registry preparation and stale registry state handling.

• Improved diagnostics when a package version already exists.

• Fixed JSON JPath parsing after bracket segments.

• Added dedicated JSON module CMake targets for examples, tests, and benchmarks.

• Added JSON module benchmark snapshots.

• Fixed vix run executable resolution for CMake projects with non-folder-name binaries.

• Improved vix run diagnostics when multiple runnable executables are produced.

• Updated watch mode to use shared runnable executable discovery.

• Improved compiler diagnostics for template errors rooted in system headers.

• Improved vix tests live progress output.

• Fixed vix tests interruption handling for Ctrl+C.

• Fixed HTTP session handling for malformed requests, invalid content lengths, oversized payloads, and unexpected EOF bodies.

• Fixed case-insensitive Connection: close keep-alive shutdown behavior.

• Strengthened Core lifecycle semantics across App, HTTPServer, RuntimeExecutor, and async TCP services.

• Fixed App::close() so shutdown is terminal, idempotent, and safe before or after listen().

• Fixed App::wait() signal-stop behavior.

• Fixed App::listen() so closed app instances cannot be restarted accidentally.

• Improved HTTP server shutdown ordering.

• Fixed async TCP stream and listener close behavior.

• Fixed async shutdown behavior for pending Asio operations and awaiting coroutines.

• Fixed runtime executor shutdown so pending posted tasks drain before worker shutdown.

• Fixed runtime executor idle detection.

• Added the official Vix Core benchmark suite.

• Added shared benchmark utilities and JSON report generation.

• Added scripts/run_core_benchmarks.sh.

• Added scripts/compare_core_benchmarks.py.

• Added the official Core v2.6.3 Release benchmark baseline.

• Updated Core README with benchmark workflow documentation.

• Added strict Core CI coverage for debug builds, sanitizer builds, Valgrind, static analysis, benchmark builds, and package export validation.

• Updated SECURITY_CI to build and run module-level tests.

• Added broad sanitizer-ready module test coverage.

• Fixed static-analysis scope so third-party, generated, example, benchmark, and test files are not blocking source analysis.

• Updated cppcheck and clang-tidy scope handling.

• Fixed sanitizer linking for many module test targets.

• Made threadpool cancellation and shutdown tests deterministic.

Compatibility

Vix.cpp v2.6.3 is a compatibility-focused release.

It does not introduce intentional breaking changes.

Existing CMake projects continue to use their CMakeLists.txt.

Existing Vix workflows such as:

vix build
vix run
vix dev
vix tests
vix check

continue to work.

The main behavior changes are improvements in correctness, diagnostics, test handling, shutdown behavior, benchmark organization, and CI scope.

For projects with unusual executable output names, vix run should now behave better because runnable executable discovery no longer depends on the project folder name.

For projects using long-running CTest suites, vix tests should now provide better progress visibility and cleaner interruption handling.

For projects running strict CI with sanitizers or static analysis, v2.6.3 should reduce false positives and linking failures while increasing real module coverage.

Notes

Vix.cpp v2.6.3 is not a flashy release.

It is an engineering release.

It makes the runtime safer, the tests more reliable, the benchmark workflow official, the CI stricter and better scoped, and the module test story stronger.

This kind of release matters because a C++ application platform cannot rely only on new features.

It must also prove that the foundation is stable.

Vix.cpp v2.6.3 is a step in that direction.

It improves confidence in the Core runtime, the CLI workflow, the module ecosystem, and the release process itself.

The direction is clear:

native C++
modern workflow
measured performance
strict CI
production-oriented reliability

That is the long-term path for Vix.cpp.