← CLI

CLI FEATURE

Runtime Maintenance

Strong CLI does not stop at code generation. It also gives operators and developers a disciplined way to refresh, validate, and diagnose a live Semitexa runtime.

Feature Guide

A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.

What this does

The framework exposes maintenance commands for code pickup, cache hygiene, generated metadata, linting, and DI probing.

How it works

server:reload rebuilds autoload and sends a graceful Swoole reload signal, cache:clear removes compiled cache artifacts, registry:sync refreshes generated registry data, and lint/test commands validate architecture and instantiation assumptions.

Why it matters

Without a disciplined maintenance surface, teams fall back to ad-hoc deletes, vague restarts, and guesswork. These commands make routine recovery and validation explicit.

Key concepts

server:reload
Gracefully reloads Swoole workers so code changes are picked up without a full container restart.
cache:clear
Clears compiled cache artifacts such as Twig output when runtime state becomes stale.
test:handler
Instantiates one handler and reports whether DI properties were wired successfully.

Maintenance Surface

Refresh, validate, and inspect the runtime without improvisation

These commands cover the maintenance loop that teams hit all the time: stale templates, generated registries, architecture drift, and suspicious DI wiring.

Graceful refresh. server:reload picks up code changes without a full container restart when the Swoole runtime is healthy.

Architectural checks. lint:* and test:handler turn framework invariants into explicit checks instead of “I hope boot catches it.”

State hygiene. cache:clear and registry:sync reduce the class of issues caused by stale compiled artifacts or outdated generated bindings.

Command Purpose Why it matters
bin/semitexa server:reload Gracefully reload Swoole workers after code changes. Fast path for normal development when containers do not need a full restart.
bin/semitexa cache:clear --twig Clear compiled Twig cache after template changes or stale render state. Cuts straight to one of the most common SSR debugging needs.
bin/semitexa registry:sync Regenerate DI-oriented registry artifacts such as contract resolvers. Keeps generated framework metadata aligned with current code.
bin/semitexa lint:handlers Validate handler signatures and payload/resource bindings. Catches architecture drift before it shows up as a weird runtime failure.
bin/semitexa test:handler Semitexa\\Demo\\Application\\Handler\\PayloadHandler\\Testing\\AiToolingHandler Probe handler instantiation and property injection directly. Useful when DI uncertainty is more valuable to test than business behavior.

Refresh changed templates safely

bin/semitexa cache:clear --twig
bin/semitexa server:reload

Check architecture after refactor

bin/semitexa registry:sync
bin/semitexa lint:handlers
bin/semitexa lint:di

Probe one suspicious handler

bin/semitexa test:handler 'Semitexa\\Demo\\Application\\Handler\\PayloadHandler\\Testing\\RuntimeMaintenanceHandler'
server:reload cache:clear registry:sync lint:* test:handler

Verified against Semitexa Ultimate 2026.09.19.1020

Runtime Maintenance

Strong CLI does not stop at code generation. It also gives operators and developers a disciplined way to refresh, validate, and diagnose a live Semitexa runtime.

How it works

server:reload picks up code changes without a full container restart. cache:clear handles stale compiled Twig templates and other artifacts. registry:sync regenerates DI-oriented registry bindings. lint:* validates handler signatures and architectural invariants. test:handler probes instantiation and DI wiring for a specific handler class.

Why this matters

Without explicit maintenance commands, teams fall back to ad-hoc shell scripts, full restarts, or trial-and-error debugging. A coherent maintenance surface keeps the runtime operable and reduces the cost of investigating unexpected behavior during development and production operations.

© Linus Torvalds: "Talk is cheap. Show me the code."

server:reload Command Implementation slice
<?phpdeclare(strict_types=1);namespace Semitexa\Core\Application\Console\Command;use Semitexa\Core\Attribute\AsCommand;use Semitexa\Core\Console\Runtime\ClearCacheAction;use Semitexa\Core\Console\Runtime\ReloadRuntimeAction;use Semitexa\Core\Console\Runtime\VerifyRuntimeAction;use Symfony\Component\Console\Command\Command;use Symfony\Component\Console\Input\InputInterface;use Symfony\Component\Console\Output\OutputInterface;use Symfony\Component\Console\Style\SymfonyStyle;/** * Lifecycle: clear cache → reload → verify * * Does NOT rebuild autoload or recreate containers. * Only safe for code changes inside existing files. * For new/renamed/deleted classes or .env changes, use server:restart. */#[AsCommand(name: 'server:reload', description: 'Gracefully reload Swoole workers (fast, code-only, no env refresh)')]class ServerReloadCommand extends Command{    protected function configure(): void    {        $this->setName('server:reload')            ->setDescription('Gracefully reload Swoole workers (fast, code-only, no env refresh)');    }    protected function execute(InputInterface $input, OutputInterface $output): int    {        $io = new SymfonyStyle($input, $output);        $io->title('Reloading Swoole Workers');        // 1. Clear cache (twig, etc.)        $clearCache = new ClearCacheAction($io);        try {            $clearCache->execute();        } catch (\Throwable $e) {            $io->warning(sprintf(                'Cache clearing failed: %s. Continuing with reload and verification.',                $e->getMessage()            ));        }        // 2. Reload: send SIGUSR1        $reload = new ReloadRuntimeAction($io);        if (!$reload->execute()) {            return Command::FAILURE;        }        // 3. Verify: health check only (no build marker check)        // Give workers a moment to cycle        sleep(2);        $verify = new VerifyRuntimeAction($io);        if (!$verify->execute(checkBuildMarker: false)) {            return Command::FAILURE;        }        $io->success('Swoole workers reloaded successfully!');        return Command::SUCCESS;    }}

Operator Habit

Good maintenance discipline

The command surface is strongest when teams use it instead of ad-hoc deletes, grep, and trial-and-error restarts.

Prefer server:reload to full restarts when the problem is only code pickup and the runtime itself is healthy.

Reach for cache:clear when templates or compiled SSR output behave inconsistently before assuming deeper corruption.

Run lint and test:handler checks early during refactors, not only after breakage becomes visible in the browser.

Keep registry sync explicit so generated binding artifacts stay reviewable rather than magical.

How it works

server:reload rebuilds autoload and sends a graceful Swoole reload signal, cache:clear removes compiled cache artifacts, registry:sync refreshes generated registry data, and lint/test commands validate architecture and instantiation assumptions.

Why it matters

Without a disciplined maintenance surface, teams fall back to ad-hoc deletes, vague restarts, and guesswork. These commands make routine recovery and validation explicit.

Key concepts

server:reload
Gracefully reloads Swoole workers so code changes are picked up without a full container restart.
cache:clear
Clears compiled cache artifacts such as Twig output when runtime state becomes stale.
test:handler
Instantiates one handler and reports whether DI properties were wired successfully.

Support Semitexa
Built for developers who prefer control over magic. Your support helps keep it fast, open, and evolving.

Donate via PayPal