Unable to create a combinator with native exchange rate adapter

[Siegrift]

I wanted to deploy a ProductApi3ReaderProxyV1 composing wstETH exchange rate with ETH/USD feed. The exchange rate adapter doesn't have a notion of dApp ID, because it doesn't care, however the ProductApi3ReaderProxyV1 enforces dApp ID to exist on the proxies it combines.

[Siegrift]

There are a few solutions:

1. Revert back to only require the proxies to be IApi3ReaderProxy, or alternatively, just AggregatorV2V3Interface (because this will work for any adapter contracts that are created to work with CL). We could still attempt the verification of dapp ID by conditionally reading IApi3ReaderProxyWithDappId.dappId. What is meh, is that this can potentially trigger the fallback function (adapters don't use it, but it's still meh).
2. Force creation of another adapter to turn dApp agnostic wrappers to dApp specific ones (to be able compatible with IApi3ReaderProxyWithDappId). I find this too extreme.
3. Similar to 1), the ProductApi3ReaderProxyV1 exposes dappId (which I like very much) but the constructor expects CL proxies and doesn't verify the dapp ID (it accepts it via constructor arg) and it's the responsibility of the deployer to make sure this is valid.

[acenolaza]

It seems that we want to re-use the wstETH/USD rate across many dapps so why not just use 1 as dappId (like current non-oev proxies) and make a one time deployment of a WstETHApi3ReaderProxyV1 that implements the IApi3ReaderProxyWithDappId instead of IApi3ReaderProxy then in combinator contracts like ProductApi3ReaderProxyV1 we could check in the constructor that underlying dappIds match OR that one of them is equal to 1

[Siegrift]

I dislike mixing the dApp ID although I can see this working in the practice as well. But I think at that point, the better question is why does the WstETHApi3ReaderProxyV1 need to bother implementing IApi3ReaderProxyWithDappId in the first place. It suggests to me that the adapter is built upon wrong expectations.

[Siegrift]

I think forcing the dApp ID on the adapter contracts is a mistake, because there can be a scenario for deploying an adapter for two non-Api3 proxies (e.g. wstETH/stETH exchange rate + stETH/ETH) where the dApp ID doesn't make sense. Doing the on-chain check for dApp ID then also doesn't make sense and it's something I disliked anyway (see point 1.). However, reading the dApp ID in the off-chain deployment script is still a good idea and we should throw an error in case they don't match, because I don't see mixing two proxies with different dApp IDs to ever be a good idea.