We are observing a troubling change in how custom apps appear to be provisioned. I originally posted in this thread, but figured it’d be good to have a record of it in this clearinghouse.
Throughout the last few months, our team has been creating a ton of apps to test auth schemes in the new apps architecture… around the end of January, those apps stopped registering a sales channel. This only came to our attention because we started seeing errors in Product queries with the publishedAt and publishedOnCurrentPublication fields in their selections. Without a “current” publication (presumably, the app’s default/included sales channel), we get Your app doesn't have a publication for this shop.
I believe this is what @David_Vrsek observed in their thread, and possibly what is causing this error reported by @Ranjan_Nagarkoti.
Given the historic availability of published_at and published_scope, I would consider this a breaking change from the REST API—or perhaps even internally, within a single GraphQL API version? We are effectively without an official way to allow merchants to selectively synchronize products with our tool (a plugin for a self-hosted content management system).
Questions
- Do we now need to instruct each of the developers implementing this plugin to create a public app and submit it for review just to get a sales channel? Will these apps be stuck in the same review queue that is experiencing major growing pains?
- When and why was this change implemented, and how can we be sure that our integration instructions are stable, going forward? Nothing in the changelog seems relevant to this.
- How should we recommend our users prevent exposing products from other sales channels to the synchronization tool? (We have some ideas here and will propose them in our upgrade guide… but so far, most of the options involve meta fields and/or examining GraphQL API results and discarding records based on user-defined conditions in our software.)
- (Bonus!) How does the Headless app create new sales channels, on-the-fly?
As an addendum to #1—if we do indeed need to ask that every one of our users submit an app for review, does that further clog up the pipeline? 
I am happy to acknowledge that our use case is unusual (a plugin used in a self-hosted or “on-prem” system) may not agree with the new “app” system’s design, which we gather is intended to handle many end-users, rather than be provisioned 1:1 with stores.
We have been making a ton of adjustments to our integration and documentation so that upgrading is sensible and tenable for users… but it’s a shame that basic tasks like accessing product data have become so cumbersome (compared to just grabbing credentials from the store admin and firing off a paginated query to the REST API).
Taking a step back… please let me know if we can provide any more detail about the shift in app capability!