-
[OPIK-6498] [QA] feat: SDK driver — FastAPI bridge for Opik Python SDK (#6707)
发布于
2026-05-14 17:28:15 +00:00 -
[OPIK-6498] [QA] feat: scaffold opik-sdk-driver FastAPI service
-
chore(sdk-driver): cap opik dep below 3.x
Per code review on the prior commit: the bridge's value is surfacing SDK
regressions in E2E tests, so let opik float on 2.x but block a silent
3.x major bump.-
feat(sdk-driver): FastAPI app skeleton with /health route
-
feat(sdk-driver): POST /projects creates via Opik Python SDK
-
fix(sdk-driver): close Opik streamer + drop atexit handler per request
Opik.init unconditionally spawns a streamer thread and registers an
atexit callback. Per-request instantiation (the spec's chosen pattern
for workspace isolation) would otherwise leak a thread and an
atexit-held reference for every POST.-
docs(sdk-driver): README with run/env/route-add instructions
-
fix(sdk-driver): propagate SDK ApiError as faithful HTTPException
Without this, the backend's 409 "Project already exists" became an opaque
500 with empty body — debuggable only by tailing the bridge's stderr.
Catch ApiError narrowly, re-raise with the original status_code and body
under HTTPException.detail. README updated accordingly.Verified against staging: duplicate create now returns 409 with
{"detail": {"errors": ["Project already exists"]}}. Pydantic 422 path
unchanged. Genuine bugs (non-ApiError) still surface as 500 + stderr.- chore(sdk-driver): forbid extra fields on ProjectCreate; link Jira from README
Pre-PR review polish.
- ProjectCreate now uses extra="forbid" so typos like {"wokspace": ...}
surface as 422 with the typo'd field path instead of silently defaulting
to the bridge's env workspace. - README's broader-architecture link points at the OPIK-6106 ticket
instead of a local-only spec path.
- chore(sdk-driver): drop uv.lock and opik upper bound
The bridge's purpose is to surface Opik SDK regressions to the E2E suite —
pinning the SDK with a committed lockfile defeats that. CI is the only
unattended consumer, and a freshuv syncper CI run picks up the newest
matching opik version, which is exactly the signal we want.Also dropping the
<3.0.0cap. Opik 3.x is not on the near-term roadmap,
and when it ships, the bridge should fail loudly so we know to bump
deliberately — not have a pre-emptive cap quietly hide its existence.uv.lockremoved from tracking and added to .gitignore.pyproject.toml:opik>=2.0.0,<3.0.0→opik>=2.0.0.- README "Run locally" notes that uv sync resolves fresh each time.
下载附件
-