From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id AFA041FF0A8 for ; Sat, 17 Oct 2026 22:32:30 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id E371221481; Sat, 17 Oct 2026 22:32:28 +0200 (CEST) From: Thomas Lamprecht To: pve-devel@lists.proxmox.com, Dietmar Maurer Subject: applied: [PATCH rest-server] rest-server: stop a json-seq stream once its client is gone Date: Sat, 17 Oct 2026 22:29:30 +0200 Message-ID: <179226896539.3596035.7744026011567707271.b4-ty@b4> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20261017161656.3529676-1-dietmar@proxmox.com> References: <20261017161656.3529676-1-dietmar@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1792269145322 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.485 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: UIWKCR5XA5SQL5G4ZMU4EBZ2FIRKLKTT X-Message-ID-Hash: UIWKCR5XA5SQL5G4ZMU4EBZ2FIRKLKTT X-MailFrom: t.lamprecht@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sat, 17 Oct 2026 18:16:56 +0200, Dietmar Maurer wrote: > The task forwarding the records of a streamed response only noticed > a closed connection when sending the next record failed. A stream > that stays silent for a long time, such as an API handler waiting on > a slow backend, thus kept running after its client went away, and so > did the work behind it, as the producer only learns of the gone > client once the stream is dropped. > > [...] FYI: Wolfgang and I picked up some older patches from an experiment I did a while ago and that covered this and some other changes that might (hopefully) be also useful for your current work. This is all now rolled out with some bigger schema changes. The test part of you change here was missing though, as its definitively useful to have I applied test part here of this patch and dropped the rest on merge conflict resolution, thanks! [1/1] rest-server: stop a json-seq stream once its client is gone commit: f553d4278995bd1e2c70aa031b28157f97312e8a