Athena Actix Crate

crates/athena-actix is the portability seam for Athena's shared Actix-facing request and runtime wrappers. The crate intentionally stops short of route business logic: it owns reusable HttpRequest helpers, request extension markers, wildcard host-routing inference, and the best-effort task spawn wrapper used by multiple gateway and admin flows.

What Lives Here Today

• Request-context extension helpers like resolved-client and disallow-JDBC markers.
• Athena-specific header extractors under headers/*.
• Direct JDBC header parsing and validation helpers.
• Wildcard host-routing config, parsing, and header inference helpers.
• spawn_best_effort_logging_task and its tests as the shared Actix runtime wrapper.

What Still Stays In athena_rs

• Route handlers and middleware that enforce Athena auth or execute business logic.
• AppState-aware request resolution and database registry lookups.
• Feature-specific response shaping for gateway, backup, schema, storage, and admin APIs.
• Domain crates that use Actix wrappers but should not own them.

Current Extraction Rule

Use athena-actix when code is primarily about reading or annotating HttpRequest, interpreting Athena-specific headers, inferring request routing from Actix headers, or spawning best-effort work on the Actix runtime.

Keep code in athena_rs when it needs:

• route-specific auth or permission policy
• application state or live pool/registry access
• domain response bodies and API contracts
• direct coordination with gateway, backup, webhook, or schema business logic

Near-Term Direction

The next Actix slices should keep shrinking the server crate around the same boundary:

1. Move more generic request and middleware wrappers only when they stop depending on domain logic.
2. Leave thin compatibility re-exports in athena_rs so downstream imports remain stable.
3. Keep domain crates consuming athena-actix instead of reimplementing header and request extension helpers.