Async Pipeline Activation

[leseb]

Problem

Praxis constructs pipelines synchronously but has no asynchronous phase for preparing pipeline-scoped resources before serving traffic.

For example, a Praxis AI pipeline may use PostgreSQL to store and rehydrate OpenAI Responses. Today, the listener can start and report Ready before the store connects. The first request may then discover invalid credentials or an incompatible schema and fail during request processing.

Lazy initialization also adds first-request latency and can race across concurrent requests. Application-specific startup logic cannot fully solve this because Praxis core owns dynamic pipeline reload and publication.

Proposal

Add an asynchronous activation phase between pipeline resolution and publication:

resolve → activate → publish

On startup, activation must succeed before listeners serve traffic. Failure prevents startup.

On reload, replacement pipelines for existing listeners must activate before being swapped into service. Failure discards the replacements and leaves the current pipelines operational.

--validate and --dump resolve pipelines without running activation or accessing activation dependencies.

Activation is pipeline-scoped, not an HttpFilter or TcpFilter lifecycle method. The immediate consumer is PostgreSQL-backed storage in Praxis AI.

Database schemas, migrations, request-time retries, and unified state management are separate concerns.

Example

A Praxis AI pipeline uses PostgreSQL to store and rehydrate OpenAI
Responses.

Today, the listener can start before the store connects. Kubernetes
reports the pod as Ready, but the first request discovers that the
credentials are invalid or the schema version is incompatible and
fails during request processing.

With pipeline activation, Praxis connects and validates the store
before publishing the pipeline. Invalid credentials fail startup; on
reload, they reject the replacement while the existing pipeline keeps
serving.

Related

• Dynamic Configuration Reloading
• Pipeline Execution Engine
• Unified State Interface

[alexsnaps]

@aslakknutsen and myself have been discussing this recently. One option that came up was indeed adding a start & stop-kinda life cycle events. The idea was to have it async indeed and probably at least -> Result<(), Err> as to being able to express readiness/successful "shutdown".

Now, I think it's important to differentiate between what possibly "Services to then be consumed by Filters" might be. In the sake of not blowing scope tho, maybe "a simple start/stop lifecycle event" might suffice for now. I'd recommend ruling out "dependencies" et al for now as concerns this proposal should concern itself with. Thoughts?

[alexsnaps]

One aspect that was raised, was stop/start cycles upon config reloads. e.g. for this, you'd probably wouldn't want to drop the connection pool to your DB on every reload (which leads me into the Services consumed by Filter idea).

[alexsnaps]

See this proposal

[shaneutt]

Proposal merged, @leseb let us know if you're down with going from there. We can also make significant changes as needed for the use cases we have lined up.

[leseb]

@alexsnaps @shaneutt thanks! @aslakknutsen proposal works for me, even though it won't fix the DB pool reload. Waiting the How now :)