Cache Process Bundle Laravel Package

Product Decisions This Supports

• Tech Stack Alignment: Justifies adoption of Laravel/Symfony for PHP-based projects requiring process management with caching (e.g., background jobs, CLI workflows, or long-running tasks). Reduces custom build effort for process isolation, signal handling, and resource cleanup.
• Future-Proofing: Supports PHP 8.5/Symfony 8 roadmap, aligning with long-term infrastructure upgrades (e.g., migrating legacy systems or adopting newer Symfony/Laravel versions). v2.2 is an incremental, non-breaking feature release — no migration work required beyond the PHP 8.2+/Symfony 7.4+ baseline already established in v2.0.
• Cost Efficiency: Avoids reinventing process management (e.g., for cron jobs, queues, or async tasks) by leveraging a battle-tested package with Symfony ProcessComponent integration. v2.2 closes the remaining feature gaps (cache-miss policy, TTL control) that would otherwise have driven custom code.
• Cache Strategy Is Now a Product Lever, Not a Code Change: v2.2 introduces on_miss (output_null / skip / fail) and expires_after on the cache tasks. This means cache freshness and cache-miss behavior become configuration decisions we can tune per workflow — directly affecting cost (reprocessing vs. stale data) and reliability (graceful degradation vs. hard failure) without engineering sprints.
• One Less Defensive-Workstream: v2.2 closes the cache-key validation gap inside the tasks themselves — key is now validated by GetTask/SetTask and an invalid key always throws. We do not need to budget a custom key-guard (or a hardening spike) before shipping customer-facing pipelines. Budget that time toward pipeline coverage instead.
• Config Ownership Shifts Left: adapter, key and value are no longer required at configuration level — no placeholders — only once merged with input. Tenant- or environment-specific workflow definitions stop being engineering tickets.
• Use Cases:
  • Background Processing: Replace custom exec()/shell_exec() calls with structured process handling (e.g., PDF generation, API polling) — now with explicit TTLs so cached outputs can't silently go stale.
  • CLI Automation: Manage external tools (e.g., docker, composer, git) with error handling, timeouts, and logging; route failures to error outputs via on_miss: skip.
  • Microservices / Expensive Operations: Decouple heavy operations (e.g., image processing) into separate processes without full containerization, and cache results with a defined lifetime.
  • Config-Driven Pipelines: Non-engineers can define pipeline defaults and supply values at input time — useful for tenant-specific or environment-specific workflows.

When to Consider This Package

Adopt When:

• Your project uses Laravel/Symfony and needs reliable process execution (e.g., CLI tools, external APIs, or long-running tasks).
• You require caching of process outputs (e.g., storing command results to avoid reprocessing) — and, as of v2.2, you need control over cache lifetime (expires_after) or defined cache-miss behavior (on_miss).
• You want strict cache-key validation as a built-in guarantee: GetTask/SetTask validate the key and throw on invalid input, so bad keys fail loudly at the task boundary rather than surfacing as silent cache pollution.
• Your workflows have varying inputs across environments/tenants and you want reusable task configuration rather than duplicating config per input.
• Your team prioritizes maintenance efficiency over custom solutions (e.g., avoiding spaghetti exec() calls).
• You’re on PHP 8.2+ and Symfony 7.4+ (or planning to upgrade to 8.x).

Look Elsewhere If:

• You need Windows-specific process handling (package focuses on Unix-like systems).
• Your use case is container orchestration (consider Docker SDK or Kubernetes operators instead).
• You require real-time process monitoring (e.g., Grafana dashboards) without caching (use Symfony ProcessComponent directly).
• You are interacting with Symfony cache adapters directly rather than through this bundle’s tasks: adapters only reject invalid keys when assert() is enabled, so validate defensively at that layer.
• Silent nulls are unacceptable and nobody owns the config: on_miss defaults to output_null. Teams must consciously set skip or fail on revenue-affecting tasks — adopt this package with a review step for cache-miss policy, not by default.
• Your team lacks Symfony/Laravel familiarity (steep learning curve for configuration).

How to Pitch It (Stakeholders)

For Executives: "This package lets us offload heavy or external tasks (e.g., file conversions, API polling) to managed processes—reducing server load and improving reliability. The v2.2 release adds two things that matter commercially: cache expiry, so we stop paying to store and serve stale results, and configurable cache-miss handling, so a cache miss degrades gracefully instead of failing a customer-facing job. It also bakes in cache-key validation, which removes a hardening item from our backlog rather than adding one. Combined with the existing PHP 8.5/Symfony 8 alignment, this is a low-risk upgrade that continues to reduce technical debt from custom scripts. It could cut our PDF generation queue failures by 30% by adding timeouts, retries, and explicit miss policies."

For Engineering: *"The CacheProcessBundle wraps Symfony’s ProcessComponent with caching and Laravel integration, giving us:

• Structured process execution (no more exec() hacks).
• Automatic output caching (avoid reprocessing identical inputs).
• Cache-miss policy per task (on_miss: output_null default, skip to route input to error outputs, fail to hard-stop) — v2.2.
• Per-item TTL (expires_after on SetTask) — v2.2, removes the need for ad-hoc invalidation jobs.
• Config-level flexibility: adapter, key, and value are no longer required in configuration, only after merging with input (AbstractCacheTask::getRequiredOptions()) — simplifies reusable/parameterised pipeline definitions.
• Key validation in the task, not just the adapter: an invalid key always throws, closing the assert()-only gap we previously had to guard ourselves.
• Clearer failure modes: non-array input raises \UnexpectedValueException (not a raw TypeError), input-supplied option values are validated through the options resolver, and duplicate adapter codes report both service IDs.
• PHP 8.5/Symfony 8 support (no blockers for upgrades).
• Signal handling (graceful shutdowns for long-running tasks).

Tradeoff: Dropped PHP 8.1/Symfony 7.3 support—if you’re stuck on those, we’ll need a migration plan. The one remaining subtlety is the on_miss default: output_null degrades silently, so set skip or fail explicitly on anything customer-facing. Otherwise, v2.2 is a drop-in, low-risk, high-reward upgrade from ad-hoc process management — and it retires a security-hardening task rather than creating one."*