From 6904bed36939e013080f0e486043e113028efbc4 Mon Sep 17 00:00:00 2001
From: "Eric Chen (from Dev Box)" <cheneric@microsoft.com>
Date: Tue, 12 May 2026 03:30:32 -0500
Subject: [PATCH] Wire Clipper.logger in V2 to restore failure telemetry

Two V2 module-level loggers (Log.ErrorUtils.sendFailureLogRequest and
userDataBoundaryHelper) reach for the static `Clipper.logger` slot,
which V2 never set up. V1's clipper.tsx contained:

  Clipper.logger = new CommunicatorLoggerPure(...)

That setter fired when the V1 Mithril sidebar bootstrapped via
injection. V2 replaced the architecture (worker opens renderer window
directly, no sidebar injection) and clipper.tsx stopped executing in
V2's flow -- so the V1 setter never fired again, and no V2-equivalent
was established. The bug has been latent throughout V2 development.
Commit 8f0dad5 later deleted the dead V1 source file, but the runtime
behavior was already broken before that cleanup.

Normal Aria telemetry (InvokeClipper, ClipToOneNoteAction,
HandleSignInEvent, GetNotebooks, all context properties) is
unaffected -- those flow through per-worker AriaLoggerDecorator
instances that never touch Clipper.logger. The static-slot path is
only used by module-level functions that have no `this` context to
hold a logger on.

Affected failure-scenario events that were silently dropped:
  - UnhandledExceptionThrown (extensionBase self.onerror handler --
    SW safety net for any uncaught crash)
  - UnclippablePage (webExtensionWorker scripting.executeScript probe
    failure on chrome:// / about:// / file:// URLs)
  - GetChangeLog (changelog HTTP fetch failure after version update)
  - JsonParse (userDataBoundaryHelper EUDB endpoint malformed JSON
    during sign-in)

Each call into Clipper.logger.logFailure threw `TypeError: Cannot
read properties of undefined (reading 'logFailure')` inside the
error handler. The browser silently swallows exceptions from
self.onerror (no recursive re-fire), so neither the original error
nor the telemetry-mechanism error reached observability.

Fix: assign Clipper.logger = this.logger in the ExtensionBase
constructor immediately after WorkerPassthroughLogger is created.
Routes module-level failure logs through the same per-worker chain
that normal telemetry uses.

Verified via SW DevTools repro: after invoking the clipper once to
spawn a worker, throwing an unhandled exception in the SW console
now POSTs a WebClipper.Failure.UnhandledExceptionThrown event to
browser.pipe.aria.microsoft.com/Collector/3.0/.

The SW-boot window (failures before any worker exists, so
WorkerPassthroughLogger has zero fan-out targets) remains a
pre-existing architectural gap shared with V1 -- out of scope.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---
 src/scripts/extensions/extensionBase.ts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/scripts/extensions/extensionBase.ts b/src/scripts/extensions/extensionBase.ts
index bbf360d0..36d23dc7 100644
--- a/src/scripts/extensions/extensionBase.ts
+++ b/src/scripts/extensions/extensionBase.ts
@@ -4,6 +4,7 @@ import {Constants} from "../constants";
 import {StringUtils} from "../stringUtils";
 import {UrlUtils} from "../urlUtils";
 
+import {Clipper} from "../clipperUI/frontEndGlobals";
 import {TooltipType} from "../clipperUI/tooltipType";
 
 import {SmartValue} from "../communicator/smartValue";
@@ -48,6 +49,9 @@ export abstract class ExtensionBase<TWorker extends ExtensionWorkerBase<TTab, TT
 
 		this.workers = [];
 		this.logger = new WorkerPassthroughLogger(this.workers);
+		// Module-level callers (Log.ErrorUtils.sendFailureLogRequest, userDataBoundaryHelper)
+		// reach for this static slot since they have no `this` to hold a logger on.
+		Clipper.logger = this.logger;
 		ExtensionBase.extensionId = StringUtils.generateGuid();
 
 		this.clipperData = clipperData;