fix: surface atproto strongref fields in upload SSE stream (#1262)
Follow-up to #1260. The staging integration tests added in that PR
failed on first run because the upload-progress SSE endpoint whitelists
which fields from job.result get emitted, and the whitelist was track_id
and warnings only — atproto_uri and atproto_cid were written to the job
record by _process_upload_background but silently dropped on the way
out. The docs and public API reference both promised these fields, and
the frontend UploadResult type reads them, but nothing on the wire
actually delivered them.
Add the two strongref fields to the SSE whitelist in upload_progress.
Same mechanism as track_id and warnings — conditionally copy if the job
result carries the key.
Regression coverage:
- tests/api/test_upload_progress_sse.py (new) — pure unit tests that
mock job_service.get_job to return a completed Job with various
result-dict shapes and assert the SSE frame contains or omits the
strongref fields correctly. Runs in CI without staging tokens, so a
future regression is caught on the PR instead of post-deploy.
- tests/integration/test_album_upload.py already asserts on the same
fields and will pass post-deploy once this lands.
Functional note: the frontend currently collects these into UploadResult
but doesn't read them (finalize sends track_ids and the backend
resolves strongrefs from DB). Exposing the fields still matches the
stated design and keeps future callers unblocked if they want to build
items[] arrays client-side the way the album edit page's reorder does.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
authored by