🤖 fix: handle template imports that outlast the request deadline
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 45/100
Hướng nghiên cứu
The issue relates to the synchronous template import flow in the aggregated API server. Start by examining the code for creating a CoderTemplate (likely in a controller or handler) and the import logic from #116. Understand how the CODER_K8S_TEMPLATE_VERSION_BUILD_WAIT_TIMEOUT environment variable and kube-apiserver's --request-timeout interact. Look for where file uploads and template versions are managed to assess idempotency or async status reporting. Testing will require setting up a slow import scenario to verify timeout behavior.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem
After #116, creating a CoderTemplate with spec.files returns only after Coder finishes importing the template. The server-side limit is CODER_K8S_TEMPLATE_VERSION_BUILD_WAIT_TIMEOUT (default 25 minutes), capped by the request deadline. Requests reach the aggregated API server through kube-apiserver, whose default --request-timeout is 60 seconds, and clients can set shorter deadlines.
If an import takes longer than the effective deadline:
- the client receives a timeout;
- the server creates no template, so nothing half-created is exposed;
- the uploaded file and template version remain in Coder;
- a retry uploads and imports again and can leave additional versions.
The maintained E2E imports a trivial template in seconds, so this path has not been exercised on a real backend. It has not been verified whether kube-apiserver's timeout applies to proxied aggregated requests in every configuration.
Options to evaluate
- Keep the synchronous Create and document the limit (current state; documented in the aggregated API server how-to).
- Return early for slow imports and expose import progress through status or conditions, so clients can wait instead of retrying.
- Make retries idempotent for identical source (for example, reuse a pending or succeeded version with the same content hash).
Trigger and owner
Owner: maintainer desk. Revisit when a user reports a slow-import timeout, when a supported quickstart path is restored, or before advertising large templates as supported.
Follow-up from #105 and #116.
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: xhigh
- Ngôn ngữ chính
- Go
- Star
- 4
- Fork
- 3
- Merge trung bình
- 3 giờ 15 phút
- Pull request đã merge (30 ngày)
- 31
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của coder/coder-k8s
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của coder/coder-k8s
Issue tương tự
-
agent-butler-finding chore
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
jordansmall/spindrift#4146 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
security
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
IBM/ibmcloud-volume-file-vpc#119 ·
-
security
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
IBM/networking-go-sdk#339 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
kubernetes-sigs/mcp-lifecycle-operator#439 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area: global bug dx priority: low
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày