Skip to content

Stabilize the HTTP API contract for typed spans and detector selection #75

Description

@adaamko

Problem

The Python detectors can emit typed spans, but the HTTP response model retains only start, end, text, and confidence. It drops category, subcategory, and reasoning. Detector selection is also inconsistent: configuration implies multiple methods, while the start script exposes only the transformer path, and the current LLM construction path is not compatible with the server's model_path argument.

The existing API tests are outside the default test suite and load a real model. The server also serializes all requests through one process-wide lock without documenting that concurrency policy.

Decisions and work

  • Decide whether the HTTP API is supported or experimental and document that status.
  • Preserve optional typed-span metadata end-to-end without breaking binary-detector clients.
  • Support configured detector methods correctly, or reject unsupported methods at the CLI/config boundary before startup.
  • Define and document concurrency semantics; replace the process-wide lock only if detector safety permits.
  • Use an injected or stub detector for network-free server/client tests and execute them in a separate API CI job.
  • Keep a real-model/real-server smoke test explicitly marked as integration or manual.

Acceptance

  • category, subcategory, and reasoning round-trip when present and remain optional for binary detectors.
  • Invalid method/config combinations fail before server startup with a clear error.
  • Offline tests cover the OpenAPI response shape, sync and async clients, and the selected concurrency policy.
  • README/API documentation contains one typed-span request and response.

This is a contract-design issue. Please do not begin a large implementation before the supported surface is decided here.

Metadata

Metadata

Assignees

No one assigned

    Labels

    correctnessCorrectness or methodology fixdesignDesign discussion or RFC before implementation

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions