v2.5.2

요약

SDK 2026.2.10을 반영해 presigned upload 실패 시 traditional 경로로 안전하게 복구합니다.

변경 사항

• synapse-sdk 의존성을 2026.2.10으로 올렸습니다.
• presigned 발급·전송·확인 실패 또는 불완전 결과에서 전체 입력을 traditional 경로로 재시도합니다 (SYN-7665).

영향 범위

• 납품처: TBD
• SDK: synapse-sdk==2026.2.10
• Breaking: 없음

검증

• requirements와 uv.lock의 SDK 2026.2.10 해소 확인
• 대상 환경 publish 검증

v2.5.1

요약

대용량 chunked upload의 finalize timeout으로 DataFile 등록이 누락되던 문제를 해결합니다.

변경 사항

• 전송 구간에 전용 read timeout을 적용하고, 끊긴 finalize는 완료 상태를 조회해 재전송 없이 이어갑니다 (SYN-7658).
• 부분 업로드 유실은 결과와 경고 로그에 드러납니다.

영향 범위

• 납품처: TBD
• SDK: synapse-sdk==2026.2.9
• Breaking: 없음

검증

• 대상 환경 publish 검증

v2.5.0

요약

upload 액션에 묶음 이름(group_name) 입력란을 추가하고, 그 값이 실제로 데이터 그룹이 되도록 SDK 핀을 2026.2.8 로 올린다. 묶음 할당을 켠 워크샵(작업 할당 단위 = 묶음)에서 작업·검수 배정이 이 묶음 단위로 동작한다.

변경 사항

• synapse-sdk 의존성 2026.2.6 → 2026.2.8 (SYN-7627).
  • 종전에는 묶음 이름을 입력해도 DataUnit.group 이 NULL 이었다 — 전송 스텝이 유닛 페이로드를 새로 조립하며 묶음 이름을 버렸고, 요청 모델이 그 키를 금지했다.
  • 이제 두 전송 경로 모두에서 groups 가 실려 backend 가 DataGroup 을 만들어 유닛에 건다. 그 FK 가 묶음 할당이 보는 유일한 키다.
  • 묶음 이름은 전송 직전에 붙어, organize 뒤 엔트리를 교체하는 플러그인에서도 유지된다. 적용 건수는 job 로그에 남는다.

영향 범위

• 납품처: 없음
• SDK: synapse-sdk==2026.2.8
• Breaking: 없음 (묶음 이름을 비워 두면 종전과 동일)

검증

• SDK 회귀 테스트 34건 + 전체 스위트 통과
• test 환경 실측 — 묶음 지정 회차는 전 유닛에 그룹 부여, 미지정 대조군은 group=null
• staging presigned 경로 확인 (후속)

v2.4.7

synapse-sdk 2026.1.176 → 2026.1.177 (데이터 유닛 배치 기본값 50 → 200, SDK SYN-7515)

v2.4.6

요약

synapse-sdk 핀을 2026.1.174 → 2026.1.176 으로 올린다. 이 버전부터 데이터 유닛 등록 실패가 재시도된다.

변경 사항

• 종전에는 배치 하나가 실패하면 그 안의 항목 전부(기본 50건)가 영구히 사라졌고 job 은 success: true 로 끝났다. 실측 — staging 이미지 100,000장 회차에서 2,000 배치 중 하나가 backend 500 을 맞아 50건이 없어졌다(u_000800.jpg ~ u_000849.jpg). 파일 전송은 100,000건 전부 성공이었으므로 잃은 것은 유닛뿐이었다.
• 이제 연결 실패 · 5xx · 408 · 425 · 429 는 지터를 넣은 백오프로 최대 2회 더 시도한다. 응답이 시작된 뒤 끊긴 경우는 재시도하지 않는다 — 서버가 이미 만들었을 수 있어 중복 유닛이 생긴다. 그 밖의 4xx 도 재시도하지 않는다.
• 플러그인 코드는 바뀌지 않았다. creating_data_unit_max_retries 로 조절하고 0 이면 끈다.

영향 범위

• 납품처: 없음 (TBD)
• SDK: synapse-sdk==2026.1.176
• Breaking: 없음

검증

• SDK 측 신규 테스트 16건 + 전체 3,763 passed (SYN-7493 · PR #413)
• staging 100,000장 재측정 — 본 릴리즈 게시 직후 수행

관련

• SDK: SYN-7493 · PR #413 · synapse-sdk 2026.1.176
• 후속: SYN-7494 — 실패분만 골라 재시도 (backend)

v2.4.5

요약

synapse-sdk 핀을 2026.1.169 → 2026.1.174 로 올린다. 업로드 동작은 v2.4.4 와 같다 — 사이에 들어간 SDK 변경 다섯은 전부 export 경로다. 이 릴리즈의 목적은 upload 플러그인 7종의 SDK 핀을 한 버전으로 모으는 것이다.

변경 사항

• requirements.txt: synapse-sdk[all]==2026.1.169 → synapse-sdk[all]==2026.1.174
• 플러그인 코드 변경 없음

2026.1.170~174 내역 (전부 export): ordering allowlist·재개 거절 사유 기록 (SYN-7487) · 호출자 지정 page_size (SYN-7487) · annotation payload URL 병렬 인출 (SYN-7490) · 만료 payload URL 재발급 (SYN-7490) · 인출 재시도·재발급 예산 (SYN-7490).

영향 범위

• 납품처: 없음
• SDK: synapse-sdk[all]==2026.1.174
• Breaking: 없음

검증

• 배포 전 정적 검증 — SDK 2026.1.174 격리 venv 에서 config.yaml action entrypoint 5/5 해소, upload step 파이프라인 8개 스텝 조립
• test env 실측 — plugin release 598, Ray job pip: synapse-sdk[all]==2026.1.174 확인, 이미지 5장 → data unit 5건 (실패 0)

v2.4.4

릴리즈 일자 2026-08-21 (CHANGELOG 기준)

Fixed

• synapse-sdk 핀을 2026.1.167 → 2026.1.169 로 올린다.
  플러그인 코드는 바뀌지 않았다 — 담는 것은 SDK 쪽 수정 둘이다.

  • [SYN-7488] 진행률이 60초 넘게 정확히 0.0 이었다 — upload_files 스텝이
    텍스트 100k 에서 61.7초, 이미지 100k 에서 101.9초 동안 0.0 에 머물렀다.
    에이전트에서 실제 스토리지로 재보니 원인이 checksum 이었다(모든 파일을
    읽는다 — 100,000×9KB 에서 16.822.6초, 이미지는 57.5GB 를 읽는다). 같은 트리를
    두 번 stat 하던 것도 함께 있었지만 그쪽은 1620초였다. 고침 둘 — stat 을
    한 번만 하고(판정을 묶음에 표시해 전략이 읽는다) checksum 구간에 진행률을
    단다(실측 비중 약 0.5%). 진행률은 여전히 단조이고 마지막이 정확히 100% 다.
  • [SYN-7487] in-process export 가 인출이 끊겨도 이어붙인다 — export 경로
    개선이다. 업로드 경로와는 무관하다.

  업로드 동작은 v2.4.3 과 같다. 이 릴리즈가 바꾸는 것은 스토리지 syscall 수와
  진행률 표시다. N=100,000 에서 stat 순회가 2회 → 1회(약 8초)이고, 종전에 바가
  멈춰 보였던 구간에서 이제 움직인다.

  아직 실측으로 확인하지 않았다 — 진행률은 backend job 레코드가 있어야 기록되고
  그것은 제품 경로에서만 만들어진다. 이 릴리즈 이후 한 회차 돌려 확인할 일이다.

---

이 Release 는 2026-08-24 에 소급 생성됐다. 본문은 그 시점의 CHANGELOG.md 해당 절을
그대로 옮긴 것이고, 릴리즈 당시의 검증 기록은 따로 남아 있지 않다 — 태그(v2.4.4)가 가리키는
커밋이 그때 배포된 코드다.

v2.4.3

릴리즈 일자 2026-08-20 (CHANGELOG 기준)

Fixed

• synapse-sdk 핀을 2026.1.166 → 2026.1.167 로 올린다.
  플러그인 코드는 바뀌지 않았다 — 담는 것은 SDK 쪽 수정 하나다.

  • [SYN-7486] 멱등이 아닌 요청이 되풀이 전송됐다 — 응답 없는 서버에 POST 를
    한 번 보냈더니 서버에 4번 도착했다. 그것이 create_data_units 였다면
    같은 유닛이 네 번 만들어졌을 것이다. 원인은 SDK 코드가 아니라 그 아래
    transport 다 — allowed_methods 에 POST·PATCH 가 들어 있어(backend 재시작
    502/503/504 를 넘기려는 것이었다) urllib3 이 read 오류에도 재시도했다.
    urllib3 기본값이 정확히 이 둘을 빼둔 이유가 그것이다: 요청이 이미 나갔으면
    서버가 처리했을 수 있다. 이제 멱등이 아닌 메서드의 read 오류에서만
    재시도를 끊는다 — 502/503/504 재시도와 connect 재시도는 그대로다.

  업로드 경로에 직접 닿는 수정이다. 이 플러그인의 유닛 등록은 POST 이고,
  지금까지 집계가 매번 실물과 일치했으므로 중복이 관측된 적은 없다. 다만 그것은
  이 실패가 그 지점에서 나지 않았다는 뜻일 뿐이고, 나면 조용히 중복이 된다.

  대가가 하나 있다 — backend 가 흔들릴 때 종전에는 재시도로 덮이던 요청이 더 빨리
  실패한다. 덮이던 것이 중복 쓰기였으므로 의도한 바이지만, 실패율이 올라가 보일 수
  있다.

---

이 Release 는 2026-08-24 에 소급 생성됐다. 본문은 그 시점의 CHANGELOG.md 해당 절을
그대로 옮긴 것이고, 릴리즈 당시의 검증 기록은 따로 남아 있지 않다 — 태그(v2.4.3)가 가리키는
커밋이 그때 배포된 코드다.

v2.4.2

릴리즈 일자 2026-08-20 (CHANGELOG 기준)

Fixed

• synapse-sdk 핀을 2026.1.164 → 2026.1.166 으로 올린다.
  플러그인 코드는 바뀌지 않았다 — 담는 것은 SDK 쪽 수정 둘이다.

  • [SYN-7485] 도착한 로그를 유실로 적고 있었다 — v2.4.1 의 N=100,000 검증(job
    306d58c5)은 유실 0 으로 끝났지만 unsent: 108 이 남았다. 그 실패의 정체를
    재현으로 특정했더니 응답 본문 수신 중 timeout 이었다 — 헤더는 왔고, 즉
    서버가 요청을 받아 응답을 만들었다. urllib3 의 재시도는 헤더 구간까지만
    덮으므로 이 실패는 한 번에 끝난다. 그래서 108건은 도착했는데 유실로
    보고된 것이다. create_logs 는 멱등이 아니므로 재시도하면 되찾는 것이 아니라
    중복이 된다. 이제 이 실패를 연결 실패와 구분해 재전송하지 않고,
    보고를 dropped·unsent·delivery_unconfirmed 셋으로 가른다.
  • [SYN-7443] 재시도가 같은 연결을 다시 썼다 — test 환경에서 50,000행 export 가
    31,550행에서 죽고 세 번 반복해도 같은 행이었다. 백오프는 서버가 회복할
    시간을 주지만 연결이 상한 경우에는 아무것도 바꾸지 않는다. 이제 재시도 직전에
    연결을 버린다. 업로드 경로와는 무관하다.

  업로드 동작은 v2.4.1 과 같다. 이 릴리즈가 바꾸는 것은 유실 보고의 정확성이다.

---

이 Release 는 2026-08-24 에 소급 생성됐다. 본문은 그 시점의 CHANGELOG.md 해당 절을
그대로 옮긴 것이고, 릴리즈 당시의 검증 기록은 따로 남아 있지 않다 — 태그(v2.4.2)가 가리키는
커밋이 그때 배포된 코드다.

v2.4.1

릴리즈 일자 2026-08-20 (CHANGELOG 기준)

Fixed

• synapse-sdk 핀을 2026.1.162 → 2026.1.164 로 올린다.
  플러그인 코드는 바뀌지 않았다 — 담는 것은 SDK 쪽 수정이다.

  • [SYN-7481] JobLog 유실 — v2.4.0 의 N=100,000 검증에서 upload_data_file 이
    100,000건 중 3,841건만 남았다. SDK 의 로그 큐 상한(2,000)에 배압이 없어
    넘치면 오래된 것부터 버렸고, presigned 업로드가 왕복 하나 없이 10만 번
    연속 로그를 내보내 생산이 전송을 압도한다. 이제 큐가 가득 차면 생산자가
    기다린다. 기본 30초가 지나면 종전처럼 버린다 — 데이터 경로가 로그보다
    우선한다. 유실이 나면 joblog_loss 이벤트로 job 로그에도 남는다.
    데이터 경로는 v2.4.0 에서도 온전했다(유닛 100,000/100,000, 집계 일치).
  • [SYN-7480] export 재시도 — 일시 backend 오류에 대한 재시도 예산을 늘리고
    실패 지점을 남긴다. (업로드 경로와는 무관하다.)

---

이 Release 는 2026-08-24 에 소급 생성됐다. 본문은 그 시점의 CHANGELOG.md 해당 절을
그대로 옮긴 것이고, 릴리즈 당시의 검증 기록은 따로 남아 있지 않다 — 태그(v2.4.1)가 가리키는
커밋이 그때 배포된 코드다.