Conversation
Extract the persistence contracts from praxis-ai-apis into a new publish=false praxis-ai-store crate with no sqlx/TLS in its dependency graph: the StateOwner identity (from_trusted_parts stays the only constructor, so the crate cannot mint a request-forged owner), the record types and StoreError, the ResponseStore and ConversationItemStore traits, and a PersistedStateBackend supertrait with a blanket impl over any type implementing both halves. Part of praxis-proxy#1258 (epic praxis-proxy#1257). The SQL backends adopt these in a follow-up. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
…t suite StoreRegistry holds Arc<dyn PersistedStateBackend> so a resolved backend provably implements both trait halves; a Conversations-requiring caller can never receive a response-only backend. OwnerScopedStore binds every request-driven access to one validated owner. The registry stays transport-free (no praxis_filter); the pipeline binding lives in the transport layer. InMemoryStore is a deterministic double for service unit tests: a single mutex makes the multi-step operations (all-or-nothing approval consumption, compare-and-swap, create/delete-items-and-sync) atomic, as the SQL backends achieve with a transaction. The test-support contract_tests suite is the shared conformance harness the in-memory and SQL backends run against. Part of praxis-proxy#1258 (epic praxis-proxy#1257). Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
…fter the response The transport layer (apis) validates an individual owner component as it parses trusted headers, before it has all three parts for from_trusted_parts, so validate_component is now public. The contract suite writes the owning response before recording its pending approvals, so a backend with a foreign key from approvals to responses accepts them. Part of praxis-proxy#1258 (epic praxis-proxy#1257). Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
Depend on praxis-ai-store and re-export its traits, records, owner, and errors from crate::store and crate root, so existing paths keep compiling. Remove the moved trait_def and types modules; split StateOwner out of state_owner.rs (the transport filter and projection stay). The SQL backends implement the moved traits and the ResponseStoreRegistry becomes a transport-bound wrapper over the SQL-free StoreRegistry, holding a combined Arc<dyn PersistedStateBackend> so a resolved backend always has both halves; the PipelineExtension binding lives here, keeping the store crate transport-free. Prove adoption by running the shared contract suite against the SQLite backend. The conversations-filter store path is unchanged (deferred to praxis-proxy#1262). Part of praxis-proxy#1258 (epic praxis-proxy#1257). Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
…d test-support Nothing in non-test src uses tokio (InMemoryStore is std::sync::Mutex; the tokio::test macros are covered by the dev-dependency), so remove it from the normal dependencies to keep tokio out of every downstream consumer's non-dev closure. Gate pub mod memory behind test-support like contract_tests, so the test double is not built or exported in the default build. Part of praxis-proxy#1258 (epic praxis-proxy#1257). Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
…i-store The registry that used DashMap moved into praxis-ai-store, so apis no longer uses dashmap. Remove it from the dependencies and the store feature; cargo machete flagged it as unused. Part of praxis-proxy#1258 (epic praxis-proxy#1257). Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
The test target ran cargo test --workspace with default features (store-postgres only), so sqlite-backed tests in praxis-test-utils constructed a sqlite ResponseStore against a backend that was never compiled and failed at runtime with backend 'sqlite' is unavailable. Add STORE_ALL_WORKSPACE_FEATURES (already used by coverage-check) so the store crates build with store-all across the workspace run; every crate still runs, none is dropped. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
Add StoreBackendFactory (backend_id, effective_key, build), BackendError with a distinct backend-unavailable variant (and a transient variant for bounded retry), a StoreCapability descriptor, an EffectiveConfigKey dedup key that redacts its Debug, and a RetireBackend hook plus ProvisionedBackend. SQL-free and crypto-free: concrete factories own their config type and any SQL/TLS. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
…e crate New publish=false praxis-ai-store-lifecycle crate depending only on the praxis-ai-store interface (crypto-free, no store-backends). It routes inline config to injected StoreBackendFactory implementations, builds and validates backends eagerly at pipeline construction (SQLite permanent-init fails the build; a transient failure retries within a bounded budget then fails as unavailable), deduplicates identical effective configs onto one pooled backend, and reuses or retires backends across a reload via a process-wide refcounted cache with explicit retirement. Nine unit tests cover the six behaviors: initial load, reload reuse, retire on last release and on changed config, unavailable-at-build, transient-then-build, and single-pool dedup. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
Wrap the existing SQLite backend as a StoreBackendFactory the lifecycle layer provisions: it parses the inline config, computes the effective dedup key, classifies a SQLite init failure as permanent (BackendError::Unavailable so the build fails closed), and closes the pool on retirement via a new close() on the SQL stores. Add a redaction helper that scrubs the connection string and any embedded credentials from an error before it surfaces. Five end-to-end tests bind the SQLite-applicable behaviors against a real file-backed SQLite backend (initial load, reload reuse, changed-config second backend, unavailable-at-build fails closed distinct from unknown-backend, single-pool dedup). Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
Mirror the SQLite factory for Postgres: parse inline config (incl. ssl_mode, ssl_root_cert, allow_private_database_url), re-run revalidate_postgres_host on every build attempt (guards DNS rebinding), build over PgTlsConfig, and close the pool on retirement. A connect failure is classified BackendError::Transient so the lifecycle cache retries it within budget, preserving the tested Postgres-transient vs SQLite-permanent semantics. Redaction and the pool fingerprint are shared across both factories. No runnable Postgres here, so the transient-then-build behavior remains machinery-covered (9 lifecycle tests). Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
…esolution Add resolve_pipelines_with_stores, which attaches a caller-provided ResponseStoreRegistry per listener. resolve_pipelines stays a thin wrapper delegating with empty registries, so the validation, CLI, and test paths are unchanged. The serve and reload paths provision backends and pass populated registries here. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
Add StoreBackendFactory::validate_config (default over effective_key, no I/O) and BackendCache::validate, a synchronous pass that fails a malformed or unknown-backend store config at pipeline construction rather than at first traffic. Pool creation stays lazy on the serving runtime: sqlx pools bind to the runtime that opens them and the server owns that runtime, unreachable at sync construction, so eager here is eager config validation. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
…e factory injection The Postgres backend factory now models ssl_client_cert, ssl_client_key, and require_certificate_authentication, matching the response-store filter config, so factory validation and build cover client-cert mutual TLS and no longer reject a config the filter accepts. Add store_backend_factories() so a binary can inject the compiled factories into the lifecycle cache. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
…ifecycle state Run the filter's TLS/auth validation from the factory (connect and validate_config), so a client cert under a non-verifying ssl_mode and the certificate-authentication compliance profile fail closed on this path as they already do in the filter. Key the Postgres dedup on the cert-path values rather than their presence, so distinct trust anchors or client identities at different paths do not collide onto one pool. Drop the unused StoreCapability descriptor and StoreRef.capability field (no runtime reads them), privatize redact_connection_error, correct the build-retry pacing comment, and fix the cert-field docs to say path, not PEM material. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
…ime background service Install an empty per-listener ResponseStoreRegistry into each pipeline via a From<StoreRegistry> bridge, and provision the configured backends into that same shared map from a Pingora background service that runs on the serving runtime. sqlx pools bind to the runtime that opens them, so provisioning must run there rather than on the config-watcher runtime a reload uses. BackendCache gains provision_into so a caller can populate a shared registry handed to it before the serving runtime exists. Store configuration is validated eagerly at startup (fatal), so a malformed or unknown-backend config fails before serving; connectivity surfaces when the pools open. Reload reuses the serving-runtime-provisioned registries: the reloaded pipeline keeps the live backends, and a changed store config is restart-required rather than re-provisioned on the watcher runtime. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
…ution The response-store filter no longer builds or caches its own backend. It resolves an owner-scoped handle from the per-request ResponseStoreRegistry via get_scoped(DEFAULT_STORE_NAME, owner), mirroring the rehydrate filter, so the tenant-isolation seam has one public request-path read. The OnceCell, the build/init/registration helpers, and the StorageBackend match are removed; the filter is a stateless unit struct that validates config at construction and rejects with 500 when a request that needs the store finds none provisioned. OwnerScopedStore gains an owner-checked persist_response_with_pending_approvals so the write path stays inside the facade. Permanent-vs-transient init policy now lives in the factory's BackendError classification and the lifecycle cache, not the filter. Connection-error redaction is threaded into the Postgres backend's runtime StoreError::Database sites: the store carries its URL and redacts it (and any embedded credentials) through a shared helper, matching the connect-time redaction the provisioning factories apply. SQLite URLs carry no credentials. The filter test suite is rewritten to the provisioning model: tests install a store into the context registry (or seed one) rather than the filter's OnceCell, and the obsolete lazy-init / self-registration / permanent-failure tests are dropped since that behavior moved to the factory and cache. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
The integration/recording harness (praxis-test-utils build_pingora_server) built pipelines with an empty ResponseStoreRegistry and never ran the store-provision background service, so after the filter migration a store-filter request through the harness found no provisioned backend and rejected with 500. Reuse the production wiring: build_store_wiring and StoreProvisionService are now public on the praxis_ai crate, and build_pingora_server installs the per-listener registries into the pipelines and registers the background service on the harness's own Pingora server, exactly as boot_server does. No second provisioning path is introduced. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
The provisioning module doc links StoreBackendFactory unqualified, but the trait moved to praxis-ai-store in praxis-proxy#1258 and the module imports only BackendError (cfg-gated). The always-compiled module doc left the link unresolved, failing cargo doc under RUSTDOCFLAGS="-D warnings". Qualify it to praxis_ai_store::StoreBackendFactory. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
…ignal The store-provision background service opens backend pools asynchronously after the HTTP listener already accepts, so a store-filter request that arrives during the provisioning window finds no provisioned backend and returns 500. The integration harness only waited for HTTP readiness, so the two Postgres store tests failed deterministically (500 vs 200): a Postgres pool open, and its TLS handshake for the mTLS variant, reliably lose the race against HTTP readiness. Add a StoreReadiness watch owned by StoreProvisionService and a cloneable StoreReadinessHandle observers read or await. Signal Ready only once every configured listener holds a lease. On a provisioning failure, keep the state non-Ready and retry with bounded backoff so a transient database or TLS failure self-heals rather than being logged and abandoned. The harness awaits Ready before the first request. The handle is reusable: the readiness endpoint and sibling workstreams read the same one. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
Expose the store readiness signal as an HTTP endpoint so an orchestrator probe gates traffic on store provisioning. It runs on its own listener because the protocol admin service owns its route set, and it composes store readiness with cluster health: ready (200) only when store provisioning is Ready and cluster health is ready, 503 otherwise, so a provisioning failure stops reporting healthy. It reads the same StoreReadinessHandle the provisioning service drives, so one state serves both the endpoint and the harness wait. The listen address comes from PRAXIS_STORE_READINESS_ADDR; enabling it is opt-in via that variable (default value 0.0.0.0:9200, path /ready) so no new port binds unless a deployment asks for it. praxis_core is untouched. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
Relocate url_security (cloud-metadata, private-range, NAT64 and special-use classification) from praxis-ai-apis into the SQL-free praxis-ai-store crate so the Postgres URL validator can keep using it after it moves out of apis in the store-backends split. Both the outbound file fetch and callout paths now share the one canonical policy from the leaf. normalize_mapped_ipv4 is inlined rather than pulled from praxis-proxy-core: praxis-proxy-core drags rustls/ring/aws-lc into its dependency graph, and the store leaf must stay crypto-free. Its unit tests move with the module. Part of the store-backends crate split (praxis-proxy#1260). Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
Move the concrete SQL backends out of praxis-ai-apis into a new praxis-ai-store-backends crate: the Postgres and Sqlite ResponseStore implementations, the connection pool, TLS and URL validation, schema management, and the StoreBackendFactory provisioning. The new crate depends only on the praxis-ai-store contracts leaf, so the SQL client crypto (sqlx TLS) is compiled in one place and a consumer that omits the crate ships none of it. praxis-ai-apis keeps a transitional dependency on the new crate and re-exports the backends at their original crate::store::* paths, so the conversations and responses filters compile unchanged. That transitional dependency is removed once #1259b and praxis-proxy#1262 take those filters off concrete-store construction, which is also when apis stops pulling sqlx transitively. Part of the store-backends crate split (praxis-proxy#1260). Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
Move the Responses persistence business logic out of the request-path filter into an in-crate service layer (crate::service::responses). ResponsesService is built from an owner-scoped store handle resolved from the registry; it owns record assembly, input-item listing, CRUD, and pending-approval coordination, constructs no backend, and holds no pool. The store, compact, and mcp_dispatch filters route persistence through it, leaving the transport free of business logic. The service runs against the in-memory backend with no pipeline and no database. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
built on #1285
Summary
Move the Responses persistence business logic out of the request-path filter into an in-crate service layer (
crate::service::responses).ResponsesServiceis built from an owner-scoped store handle resolved from the registry; it owns record assembly, input-item listing, CRUD, and pending-approval coordination, constructs no backend, and holds no pool. The store, compact, and mcp_dispatch filters route persistence through it, leaving the transport free of business logic. The service runs against the in-memory backend with no pipeline and no database.Part of the store-layer split (#1257): with the SQL backends behind their own crate (#1260) and the response-store filter registry-only (#1259), the persistence logic now moves off the filter into a service the transport calls.
Related issue
Closes #1261.
Part of #1257.
Validation
Rebased clean on #1260 (feat/1260-store-backends); the pre-flagged store/mod.rs conflict did not occur, since this edits apis/src/openai/responses/store/mod.rs while #1260 edits apis/src/store/mod.rs.
coverage-check reports red, but the failure is inherited from #1260, not this change. #1260 moved the SQL backends to store-backends/src/postgres.rs, which the Makefile coverage exclusion regex (store/postgres.rs) no longer matches, so the uncovered DB-dependent lines now count against the total. Measured, this change is coverage-neutral: the base is 94.833% without it and 94.832% with it, and excluding the moved postgres.rs the stack is 95.56%. The exclusion fix lands on #1260.
Checklist
Breaking changes
Internal reorganization; no public API or runtime behavior change. Responses persistence moves from the store, compact, and mcp_dispatch filters into crate::service::responses; the filters call the service instead of assembling records inline.