Context
When SFTP session creation fails, WebUI displays "생성 가능한 업로드 세션 개수 한도에 도달했습니다" (NumberOfSFTPSessionsExceeded) regardless of the actual root cause. Reported on two customer sites:
- NHN AICA (core 24.9.4):
max_concurrent_sftp_sessions=5, actual usage 1. Real cause was sftp-agent port-pool exhaustion (exited SFTP containers piled up, blocking the port range). Manager logs showed SessionEnqueuedEvent → SessionCancelledEvent(reason=FAILED_TO_START), but WebUI displayed "limit reached".
- SEC Mobile AI Div (core 25.5.0):
max_concurrent_sftp_session=3, actual usage 0. Real cause was a bad cert-mount option in agent-docker-container-opts.json preventing container creation. WebUI still displayed "limit reached".
Both cases caused customer support escalation ("why is my quota set to 1?").
Scope
Three tightly coupled UI improvements, delivered as one PR:
-
Surface error classification on the SFTP session failure modal
- Files:
react/src/components/SFTPServerButton.tsx, react/src/components/SFTPServerButtonV2.tsx
- Extend
useErrorMessageResolver (in backend.ai-ui) with a detail mode that exposes statusCode and error_code alongside the message.
- Apply detail mode in the SFTP session error modal so operators can distinguish 4xx (policy/quota) from 5xx / FAILED_TO_START (agent/port/mount) cases.
-
Add "Go to upload sessions" CTA in the SFTP error modal
- On failure, give the user a one-click path to the upload session management view so stale sessions can be cleaned up.
-
Clean up unused i18n keys
- Keys
data.explorer.NumberOfSFTPSessionsExceededTitle/Body and data.explorer.SFTPSessionNotAvailable exist in 22 language files but have no consumer in the current React/TS tree. Remove or replace with new classification-aware keys.
Why one PR
All three touch the same SFTP failure modal and its i18n keys. Splitting would leave half-improvements in main.
Out of scope
- Session Launcher storage-host fetch failure handling (different flow).
- Backend port-pool tracking / SFTP container GC (backend concern).
- Idle indicators in the upload session list (separate UX issue).
Acceptance criteria
- SFTP session creation failure modal shows the HTTP status code and error_code (when present) alongside the localized message.
- Modal includes a button that navigates to the upload session management view.
- Unused i18n keys are either removed or replaced (no orphan keys remain across the 22 locale files).
bash scripts/verify.sh passes.
JIRA Issue: FR-2898
Context
When SFTP session creation fails, WebUI displays "생성 가능한 업로드 세션 개수 한도에 도달했습니다" (NumberOfSFTPSessionsExceeded) regardless of the actual root cause. Reported on two customer sites:
max_concurrent_sftp_sessions=5, actual usage 1. Real cause wassftp-agentport-pool exhaustion (exited SFTP containers piled up, blocking the port range). Manager logs showedSessionEnqueuedEvent→SessionCancelledEvent(reason=FAILED_TO_START), but WebUI displayed "limit reached".max_concurrent_sftp_session=3, actual usage 0. Real cause was a bad cert-mount option inagent-docker-container-opts.jsonpreventing container creation. WebUI still displayed "limit reached".Both cases caused customer support escalation ("why is my quota set to 1?").
Scope
Three tightly coupled UI improvements, delivered as one PR:
Surface error classification on the SFTP session failure modal
react/src/components/SFTPServerButton.tsx,react/src/components/SFTPServerButtonV2.tsxuseErrorMessageResolver(inbackend.ai-ui) with a detail mode that exposesstatusCodeanderror_codealongside the message.Add "Go to upload sessions" CTA in the SFTP error modal
Clean up unused i18n keys
data.explorer.NumberOfSFTPSessionsExceededTitle/Bodyanddata.explorer.SFTPSessionNotAvailableexist in 22 language files but have no consumer in the current React/TS tree. Remove or replace with new classification-aware keys.Why one PR
All three touch the same SFTP failure modal and its i18n keys. Splitting would leave half-improvements in main.
Out of scope
Acceptance criteria
bash scripts/verify.shpasses.JIRA Issue: FR-2898