Packaging Connected App in 2gp package - CLI says package is deleted?

Question

Throw away account to protect the guilty.

I have an ISV app that I'm helping someone attempt to package. One of it's components is a Connected App, and I researched the careful dance described here: (https://developer.salesforce.com/docs/atlas.en-us.232.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_connected_app.htm) I have, to my understanding followed the process detailed there to the letter.

I have:

1. Created an org (named 1gpPkg) using the environment hub, and registered the namespace throwaway.
2. Created a second org (named devHub) using Environment hub, and enabled it to be the devHub.
3. Created a package in 1gpPkg org that is managed containing nothing but the connected app. Named the package OauthCreds
4. uploaded a managed and released version of that package. full package name is throwaway__OauthCreds
5. waited an hour for the package to propagate.
6. created metadata in force-app/main/default/connectedApps/throwaway__OauthCreds.meta-xml that looks like this:

<ConnectedApp xmlns="http://soap.sforce.com/2006/04/metadata">
    <developerName>throwaway__OAuthCreds</developerName>
    <label>A Connected App</label>
    <version>1.0</version>
</ConnectedApp>

1. I tripple checked the package version. it's 1.0 I swear. (insert picard saying there are 4 lights meme)
2. Tried to create a new package version of the 2gp package containing the rest of the app.

When I run sfdx force:package:version:create -p MyAppName -x -w 20 -f config/project-scratch-def.json I get this (useless) message back:

›   Warning: Based on feedback from Salesforce Partners, we’re enhancing the package ancestry feature. Starting in Spring ‘22, the 
 ›   ancestor version field is required when you create a package version. Look for more details, including how to override the 
 ›   ancestry requirement, in the packaging section of the Spring ‘22 Salesforce Release Notes and in the Salesforce DX Developer 
 ›   Guide.
Request in progress. Sleeping 30 seconds. Will wait a total of 1200 more seconds before timing out. Current Status='Queued'
Request in progress. Sleeping 30 seconds. Will wait a total of 1170 more seconds before timing out. Current Status='Verifying features and settings'
Request in progress. Sleeping 30 seconds. Will wait a total of 1140 more seconds before timing out. Current Status='Verifying metadata'
ERROR running force:package:version:create:  OAuthCreds: Installing an app (OAuthCreds) that has been deleted.

I'm helping a friend who initially submitted a support request about this, but it's been 28 days and 7 escalations without response... Help me SFSE, you're my only hope

Answer 1

You don't actually need to package the Connected App, especially when all/many of your clients use the same connected app with the same secret/ID and same mobile app (for example). The important thing is the ID for the app, not where it is. A connected app can be connected to any org.

Rather than package it, just create the Connected App on the target production org (or PBO, see below) and use the secret/ID from this in the mobile app/external system.

A packaged connected app generates a unique ID/key each time it is installed, I believe. This then means your authentication (e.g. in a mobile app using OAuth 2) must be uniquely linked to that instance, so you have to somehow get that secret/ID into the (dedicated) mobile app/external system too.

I believe the only use case for packaging a connected app is when you have a per-installation variant of the client, but even then this is troublesome around sandboxes (including scratch orgs).

We did not take this approach.

Since we build the "branded" mobile app (from our own source code) on behalf of our large customers, we ask that they create (or have us create) a connected app on their production org, and we use the ID/key in their app variant. Smaller customers can use our "unbranded" app with our connected app that we created on our PBO (Partner Business Org). As long as our PBO (and thus our business) is still around, the Connected App will remain active.

NB: You can block or allow use of specific connected apps against a given org through the Setup UI on that org.