This is a comment left during a code review.
Path: src/media/fetch.ts
Line: 155-156

Comment:
**Intermediate attempt errors silently discarded in 3-attempt chains**

`primaryError ??= err` only records the first failure. With the new three-tier chain (default → IPv4-only → pinned IP), the second attempt's error (IPv4-only) is never stored anywhere: `primaryError` already holds attempt 0's error and is never updated after that.

When the chain exhausts, the combined error reports `primaryError = err[0]` and `cause = err[2]`, silently dropping `err[1]`. For debugging a multi-tier Telegram connectivity failure this can obscure the real sequence.

A simple fix is to accumulate all errors, for example as a chain:

```typescript
// instead of primaryError ??= err:
primaryError = primaryError === undefined ? err : new Error("retry attempt failed", { cause: err });
```

Or, if the combined-error message only ever needs to mark "there was a first error and a last error", the current shape is at least documented — but it should have a comment explaining the intentional loss of middle attempts.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/telegram/src/fetch.ts
Line: 160-165

Comment:
**No guard for empty `addresses` in `createPinnedHostnameLookup`**

`selected[0]` can be `undefined` when `pinnedHostname.addresses` is an empty array, causing `first.address` to throw at runtime. Today this is prevented by the external guard in `createTelegramTransportAttempts`:

```typescript
if (TELEGRAM_FALLBACK_IPS.length === 0) {
  return attempts;
}
```

…but `createPinnedHostnameLookup` accepts any `PinnedDispatcherPolicy["pinnedHostname"]` and has no enforcement on its own. A caller that passes an empty `addresses` list (e.g. from a `PinnedHostnameOverride` with `addresses: []`) would get an opaque crash on the first DNS resolution.

Consider adding a guard before the `selected[0]` dereference:

```suggestion
    const first = selected[0];
    if (!first) {
      resolvedCallback(new Error(`No usable address for pinned hostname ${pinnedHostname.hostname}`) as unknown as null, "", 0);
      return;
    }
    (resolvedCallback as (err: null, address: string, family: number) => void)(
      null,
      first.address,
      first.family,
    );
```

Or at minimum a non-null assertion with an explanatory comment pointing at the invariant enforced by the caller.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/media/fetch.ts
Line: 158-160

Comment:
**Unreachable defensive guard**

After the loop, `result` is either set (successful attempt + `break`) or an error was thrown. Since `attempts` is guaranteed non-empty (the fallback `[{ dispatcherPolicy: undefined, lookupFn }]` ensures at least one element), the `if (!result)` branch can never execute. This makes `result` typed as `... | undefined` when in practice it's always defined at this point, which forces the `!result` check to satisfy TypeScript rather than guard against a real case.

Replacing `let result: ... | undefined` with a typed `let result!: ...` (definite-assignment assertion) or restructuring to assign at the point of success would make the intent clearer and remove the dead branch.

How can I resolve this? If you propose a fix, please make it concise.