Record business_platform_id not partner_id in remaining cases

[amcaplan]

WHY are these changes introduced?

Fixes https://github.com/Shopify/develop-app-inner-loop/issues/2025

Prerequisite here

WHAT is this pull request doing?

• Introduces organization source tracking in CLI metadata and analytics
• Updates environment and info commands to include organization source information
• Adds organization source as a required property for developer platform clients, as sometimes that's all we have to go on (if we haven't yet fetched the org)
• Ensures consistent organization source handling across Partners and Business Platform clients

How to test your changes?

1. Run shopify app env pull with both Partners and Business Platform apps
2. Run shopify app info with both Partners and Business Platform apps
3. Verify metadata includes correct organization source in analytics

Measuring impact

• Existing analytics will cater for this addition

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes

[amcaplan]

• Record business_platform_id not partner_id in remaining cases #5138 👈 (View in Graphite)
• Make organization source required #5137
• Include business platform ID in bugsnag info #5136
• Report business platform ID instead of partner ID when relevant #5120
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	75.33% (-0.02% 🔻)	8847/11745
🟡	Branches	70.54% (-0.07% 🔻)	4293/6086
🟡	Functions	75.21% (+0.01% 🔼)	2315/3078
🟡	Lines	75.86% (-0.02% 🔻)	8364/11025

Show new covered files 🐣

St.❔	File	Statements	Branches	Functions	Lines
🟢	... / add-uid-to-extension-toml.ts	88%	83.33%	100%	100%

Show files with reduced coverage 🔻

St.❔	File	Statements	Branches	Functions	Lines
🟡	... / context.ts	71.3% (+0.54% 🔼)	61.67% (-0.4% 🔻)	73.91%	73.91% (+0.58% 🔼)
🟢	... / use.ts	100%	95% (-5% 🔻)	100%	100%
🟢	... / ConcurrentOutput.tsx	98.36% (-1.64% 🔻)	88% (-4% 🔻)	100%	98.33% (-1.67% 🔻)

Test suite run success

1994 tests passing in 902 suites.

Report generated by 🧪jest coverage report action from 52e68e1

[github-actions]

We detected some changes at packages/*/src and there are no updates in the .changeset.
If the changes are user-facing, run "pnpm changeset add" to track your changes and include them in the next release CHANGELOG.

[github-actions]

Differences in type declarations

We detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:

• Some seemingly private modules might be re-exported through public modules.
• If the branch is behind main you might see odd diffs, rebase main into this branch.

New type declarations

We found no new type declarations in this PR

Existing type declarations

packages/cli-kit/dist/public/node/monorail.d.ts

@@ -16,6 +16,7 @@ export interface Schemas {
             env_plugin_installed_all?: Optional<string>;
         };
         public: {
+            business_platform_id?: Optional<number>;
             partner_id?: Optional<number>;
             command: string;
             project_type?: Optional<string>;

packages/cli-kit/dist/public/node/plugins.d.ts

@@ -16,7 +16,7 @@ import { Config, Interfaces } from '@oclif/core';
  * @returns A dictionary of plug-in names to the response from the hook.
  */
 export declare function fanoutHooks<TPluginMap extends HookReturnsPerPlugin, TEvent extends string & keyof TPluginMap>(config: Interfaces.Config, event: TEvent, options: TPluginMap[typeof event]['options'], timeout?: number): Promise<Partial<TPluginMap[typeof event]['pluginReturns']>>;
-type AppSpecificMonorailFields = PickByPrefix<MonorailEventPublic, 'app_', 'project_type' | 'api_key' | 'partner_id'> & PickByPrefix<MonorailEventPublic, 'cmd_extensions_'> & PickByPrefix<MonorailEventPublic, 'cmd_scaffold_'>;
+type AppSpecificMonorailFields = PickByPrefix<MonorailEventPublic, 'app_', 'project_type' | 'api_key' | 'partner_id' | 'business_platform_id'> & PickByPrefix<MonorailEventPublic, 'cmd_extensions_'> & PickByPrefix<MonorailEventPublic, 'cmd_scaffold_'>;
 type AppSpecificSensitiveMonorailFields = PickByPrefix<MonorailEventSensitive, 'app_'>;
 export interface HookReturnsPerPlugin extends HookReturnPerTunnelPlugin {
     public_command_metadata: {

[isaacroldan]

Do we have the org or any info we can pass to this function to not rely on checking if there is an ID in the config?

[amcaplan]

Yeah, I'm not really thrilled with this, but all we have to work with is the app configuration itself. We might eventually move to a system where we remove the organization_id and instead hit the backends to find which is the correct one, but for now I think this is what we've got.

[isaacroldan]

Actually, I think we can remove this "logMetadata" completely.
The config use command will call linkedAppContext after this, which already handles the metadata for org+app.

[amcaplan]

It's also used in getAppConfigurationState here, will that be a problem?

[isaacroldan]

No that's ok, the linkedAppContext handles the metadata after loading the app, so is safe to rely on that as a single place for all api-key/org metadata