From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 432801FF138 for ; Wed, 04 Feb 2026 13:23:28 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D5FC6125DA; Wed, 4 Feb 2026 13:23:59 +0100 (CET) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 04 Feb 2026 13:23:55 +0100 Message-Id: Subject: Re: [RFC datacenter-manager/proxmox 0/7] inject application context via rpcenv for easier integration testing From: "Lukas Wagner" To: "Robert Obkircher" , X-Mailer: aerc 0.21.0-0-g5549850facc2-dirty References: <20260129134418.307552-1-l.wagner@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1770207759950 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.035 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_SHORT 0.001 Use of a URL Shortener for very short URL RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. 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: DDRX3JA2U4XV5IJG27IVK4UKJQD3OGVH X-Message-ID-Hash: DDRX3JA2U4XV5IJG27IVK4UKJQD3OGVH X-MailFrom: l.wagner@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 Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue Feb 3, 2026 at 12:02 PM CET, Robert Obkircher wrote: > On 1/29/26 14:43, Lukas Wagner wrote: >> What I'm not so sure about yet and where I have not done any experiments= is the >> case where the entire API handler is defined in a shared crate. These of= course >> cannot access the product-specific struct. Many of these rely on some fo= rm of >> static initialization, either directly or indirectly (e.g. >> proxmox-product-config). >> >> I'd be happy about any ideas for these cases. > > I'm not very familiar with any of this, but have you considered making > dependency injection more flexible? > > If API handlers can choose what they want (e.g. with a InjectedRef > parameters) they never need to know about an application specific type > like PdmApplication. > > Tests would then also now exactly which dependencies to construct and > they could just pass them by reference. > > As far as I can tell, Actix [1] also seems to support multiple types > for app_data and Axum has a slightly different approach with the > FromRef trait used for substates [2]. > > [1] > https://docs.rs/actix-web/latest/actix_web/struct.Scope.html#method.app_d= ata > [2] https://docs.rs/axum/latest/axum/extract/struct.State.html#substates > Hi Robert, thank you a lot for your input. This is indeed an interesting idea. I've checked out how this is implemented in actix-web, internally these state objects basically boil down to a map of TypeId -> Box. The 'extractors' in the function signatures are nice, I'm wondering if something like this could be integrated retroactively without introducing huge breaking changes into our API server stack. If not, we still could have such a map somewhere in rpcenv and then have something like=20 let xyz_context =3D extract_context::(&rpcenv)?; which then does the lookup in the map and perform the cast from Any. The context type would then be defined by the shared crate, instantiated by the application and injected during server startup, similar to how I handled the PdmApplication struct in this RFC. I'll do some experiments and send an updated RFC if something interesting comes out. Thanks a lot!