project deploy start exits 10 "fetch failed" when the connection closes between status checks; the deploy keeps running
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
- 53/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- javascript, node.js
- Lĩnh vực
- cli, networking
Hướng nghiên cứu
Start by reading source-deploy-retrieve's MetadataTransfer.isRetryableError and pollStatus path, then check the reported jsforce and undici error shapes. Reproduce the dropped connection with the CONNECT proxy described in the issue. Done when the deploy keeps polling after this transient failure and returns its final result; add coverage for the retryable error if the repository has relevant tests.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Before You Submit
- I'm using the latest version of Salesforce CLI (reproduced on 2.157.8)
- I've searched the existing issues (related: #3622, which is about HTTP/2 crashes in data commands; this one is HTTP/1.1 and handled, but not retried)
Command
sf project deploy start (also deploy validate, deploy quick: any command that waits with MetadataApiDeploy.pollStatus)
Org Type
Sandbox
Did this work before?
Not sure
Summary
When Salesforce closes the HTTP connection between two deploy status checks, sf project deploy start --wait N exits 10 with MetadataTransferError: Metadata API request failed: fetch failed, while the deploy keeps running and later succeeds in the org. In CI this marks a successful deploy as failed.
Cause, as far as we can read the code:
- jsforce-node's
fetchWithRetriesretries onlyGET/PUT/HEAD/OPTIONS/DELETE;checkDeployStatusis a SOAPPOST, so the request is not retried. - source-deploy-retrieve
MetadataTransfer.isRetryableErrortolerates network errors by matchingerror.messageagainstECONNRESET,socket hang up, etc. With undici the message isfetch failed(the cause,SocketError: other side closed,UND_ERR_SOCKET, is inerror.cause), so none match andpoll()rethrows. Same list in SDR 13.6.0 and 13.12.0.
We saw it 4 times in 20 minutes, from two different machines (GitHub Actions runners and a cloud VM), against the same sandbox, with no Trust incident.
Steps to reproduce
The closure is intermittent; we reproduce it deterministically with a local CONNECT proxy that closes the tunnel of one status check:
- Run a CONNECT proxy on 127.0.0.1:18081 that, after ~20 s, closes the next tunnel right after the client sends its request (about 20 lines of Node
net; happy to share). HTTPS_PROXY=http://127.0.0.1:18081 sf project deploy start --dry-run --source-dir force-app/main/default/classes -o <sandbox> --test-level RunSpecifiedTests --tests SomeTest --wait 10 --json
Expected Result
The CLI treats the closed connection as a transient network error (as it does for ECONNRESET), keeps polling, and returns the deploy's final result (exit 0 here).
Actual Result
Exit 10 after the first closed connection:
{"status":10,"name":"MetadataTransferError","message":"Metadata API request failed: fetch failed","data":{"id":"0Af..."}}
The CLI log (~/.sf/sf-YYYY-MM-DD.log) has:
TypeError: fetch failed
at Object.processResponse (undici/lib/web/fetch/index.js:272:16)
at async fetchWithRetries (@jsforce/jsforce-node/lib/request.js:111:25)
caused by: SocketError: other side closed
at TLSSocket.onHttpSocketEnd (undici/lib/dispatcher/client-h1.js:1024:22)
sf project deploy report --job-id <id> afterwards shows the job Succeeded.
Suggested fix
In isRetryableError, also inspect error.cause (and error.cause.cause) for code in UND_ERR_SOCKET, ECONNRESET, ETIMEDOUT, …, or add fetch failed / other side closed to retryableErrors. A status check is read-only, so retrying it is safe.
Our workaround: when the command exits 10 with this error and data.id, we follow the same job with sf project deploy report --job-id <id> --wait <remaining>.
System Information
@salesforce/cli/2.157.8 linux-x64 node-v24.22.2
@salesforce/source-deploy-retrieve 13.11.0, @jsforce/jsforce-node 3.12.0, undici 8.12.3
(also @salesforce/cli 2.156.5: SDR 13.6.0, undici 8.12.2)
- Ngôn ngữ chính
- Không có dữ liệu ngôn ngữ
- Star
- 575
- Fork
- 80
- Merge trung bình
- 5 giờ 58 phút
- Pull request đã merge (30 ngày)
- 4
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 forcedotcom/cli
-
area:afdx bug owned by another team
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
forcedotcom/cli#3676 · 3 bình luận ·
-
sf agent mcp asset replace --assets null throws raw TypeError instead of InvalidShapeCó thể đã có người làm @konkonrong-lgtm đã nhận 91 ngày trước. Đang mởarea:afdx bug investigating owned by another team validated
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
forcedotcom/cli#3625 · 4 bình luận ·
-
area:afdx bug owned by another team
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
forcedotcom/cli#3608 · 2 bình luận ·
-
investigating regression validated
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
forcedotcom/cli#3686 · 3 bình luận ·
-
area:mdapi investigating validated
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 65/100
forcedotcom/cli#3684 · 1 bình luận ·
Tất cả issue của forcedotcom/cli
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
criticalmanufacturing/cli#909 ·
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 76/100
vercel-labs/just-bash#756 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area/auth comp/cli P2 type/feature
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
NousResearch/hermes-agent#153245 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Expression with ill-formed typeĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 94/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug need-triage SaaS security
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày