Do not crash on metrics errors

[dmerand]

WHY are these changes introduced?

Resolves incident #inv-18682 (February 2026 OTLP failures)

When the OTLP telemetry endpoint is unavailable or experiencing failures, the CLI currently crashes with unhandled errors, forcing users to run commands with SHOPIFY_CLI_NO_ANALYTICS=1 as a workaround. This violates the principle that telemetry should be transparent to users - it should never impact CLI functionality.

Related to: PR #6851 (adds Bugsnag reporting for telemetry failures)

WHAT is this pull request doing?

Changes:

Always resolve the OTEL metrics emitter - There is no need to halt execution/reject the emitting process if OTEL reporting fails. This is a non-critical process, and we should allow things to continue to function normally even if this fails

HOW is this fixing things?

• Commands exit with EXIT_CODE=0 now as we are always resolving. Previously, they were exiting with 1

1. CLI command finishes                                                                                                          
     ↓                                                                                                                             
  2. postrun hook (cli-kit/.../hooks/postrun.ts)                                                                                   
     → calls reportAnalyticsEvent()                                                                                                
     ↓                                                                                                                             
  3. reportAnalyticsEvent (analytics.ts:44)                                                                                        
     → Promise.all([doMonorail(), doOpenTelemetry()])                                                                              
     → has try/catch, BUT...                                                                                                       
     ↓                                                                                                                             
  4. doOpenTelemetry → recordMetrics (otel-metrics.ts:58)                                                                          
     → calls recorder.otel.record() on counters/histograms                                                                         
     ↓                                                                                                                             
  5. BaseOtelService.record() (BaseOtelService.ts:~140)                                                                            
     → instrument.record(value, labels)                                                                                            
     → void meterProvider.forceFlush({}).catch(() => {})   ← FIRE-AND-FORGET                                                       
     ↓                                                                                                                             
  6. MeterProvider.forceFlush()                                                                                                    
     ↓                                                                                                                             
  7. InstantaneousMetricReader.onForceFlush()  [throttled to 1000ms]                                                               
     → this.collect({})  — gathers accumulated metrics                                                                             
     → this._exporter.export(resourceMetrics, callback)                                                                            
     ↓                                                                                                                             
  8. OTLPMetricExporter sends HTTP request to OTEL collector                                                                       
     → callback fires with { code: SUCCESS | FAILED, error? } 
     → previously rejected any errors, now we log/report them, but always resolve

[dmerand]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Do not crash on metrics errors #6854 👈 (View in Graphite)
• Log on metrics submission errors #6851
• main

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

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	78.91%	14557/18448
🟡	Branches	73.23%	7223/9863
🟡	Functions	79.12%	3705/4683
🟡	Lines	79.25%	13763/17366

Test suite run success

3775 tests passing in 1455 suites.

Report generated by 🧪jest coverage report action from 10c96e1

[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

packages/cli-kit/dist/public/node/vendor/otel-js/service/FailSafeOtelService.d.ts

import type { MetricAttributes } from '@opentelemetry/api';
import { OtelService, OnRecordCallback } from './types.js';
/**
 * Wraps an OtelService to ensure telemetry failures never crash the CLI.
 *
 * This service attempts to record metrics on a "fail-safe" basis - if recording
 * fails, the error is logged (in verbose mode) but not propagated.
 * This ensures telemetry infrastructure issues (like OTLP endpoint outages) don't
 * block developer workflows.
 *
 * Only wraps the methods that are actually called from outside the service.
 * Initialization errors are handled by the caller.
 *
 * Related: incident #inv-18682 (February 2026 OTLP failures)
 */
export declare class FailSafeOtelService {
    private readonly inner;
    private hasLoggedError;
    constructor(inner: OtelService);
    get serviceName(): string;
    record<TAttributes extends MetricAttributes = any>(...args: Parameters<OnRecordCallback<TAttributes>>): void;
    private logError;
}

Existing type declarations

We found no diffs with existing type declarations

[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.

Caution

DO NOT create changesets for features which you do not wish to be included in the public changelog of the next CLI release.

[dmerand]

We should perhaps test that the diag.error comes through in this and the above case.

[dmerand]

Nit: This isn't anything we did in this PR, but this class name isn't correct any more -- perhaps a miss when vendoring?

[dmerand]

Should we also add a test case for export returning synchronous exceptions?