Enforce maxBytes before buffering hosted content

valResp.arrayBuffer() reads the entire /hostedContents/{id}/$value payload into memory before the size guard runs (buffer.byteLength > params.maxBytes), so oversized attachments are still fully downloaded and buffered. In environments where users can send large Teams files, this can cause avoidable memory spikes or OOM despite maxBytes being configured; the response body should be size-limited while reading (or rejected from headers before buffering).

Useful? React with 👍 / 👎.

The fetchWithSsrFGuard(...) call in the item.id branch can throw (network error, SSRF block, invalid URL). Because it's not wrapped in a try/catch, a single hosted content download failure would reject downloadGraphHostedContent and abort all subsequent attachment handling for the message. Consider catching errors around this fetch and continueing so failures remain per-item, consistent with the rest of this loop's error-handling strategy.

Buffer.from(await valResp.arrayBuffer()) reads the full response into memory before enforcing maxBytes. This bypasses the repo's usual max-bytes protection (e.g., readResponseWithLimit / fetchRemoteMedia patterns) and could allow oversized hosted content to cause high memory usage even though you later continue when buffer.byteLength > params.maxBytes. Prefer enforcing maxBytes while reading (e.g., check content-length and/or read the body with a byte limit) so large payloads are rejected early.

When overriding itemContentType from the response header (content-type), consider normalizing/trimming it (e.g., via normalizeContentType) before passing it into mime detection / saveMediaBuffer. This keeps behavior consistent with normalizeGraphAttachment and avoids propagating header values with unexpected whitespace/casing.

There are existing tests for hostedContents when contentBytes is inlined, but this new fallback path (item.id -> /{id}/$value) isn’t covered. Please add a unit test that simulates a hostedContents list item with id but no contentBytes, and asserts that the code fetches .../hostedContents/{id}/$value and stores the returned bytes/content-type.

Restrict auth token forwarding to specific Traffic Manager host

Adding "trafficmanager.net" to the auth allowlist causes fetchWithAuthFallback to attach bearer tokens to any https://*.trafficmanager.net URL after a 401/403, because host checks are suffix-based (isUrlAllowed). Since Traffic Manager subdomains can be tenant-controlled, a malicious attachment URL like https://attacker.trafficmanager.net/... can trigger token forwarding and exfiltrate Graph/Bot Framework access tokens; this should be narrowed to the exact Microsoft endpoint(s) needed (for example smba.trafficmanager.net) rather than the whole parent domain.

Useful? React with 👍 / 👎.

Enforce byte limit when /$value lacks Content-Length

The new hosted-content fallback only rejects oversized payloads when content-length is present, then calls arrayBuffer() unconditionally; if the server omits or misreports that header (valid for chunked responses), an attachment larger than maxBytes is still fully buffered in memory before being discarded. This defeats the configured size guard for that response class and can cause avoidable memory spikes under large DM/channel attachments.

Useful? React with 👍 / 👎.

Use token provider API contract when fetching tenant token

downloadMSTeamsGraphMedia accepts tokenProvider as MSTeamsAccessTokenProvider (single-argument getAccessToken(scope)), but this branch calls getAccessToken(authConfig, scope) whenever conversationTenantId differs. If a provider follows the declared interface yet exposes connectionSettings metadata, the first argument becomes an object instead of a scope string, so token acquisition can fail and Graph media fallback returns tokenError for cross-tenant messages. This should be gated by an explicit capability check or a dedicated tenant-scoped provider path rather than invoking an undeclared overload.

Useful? React with 👍 / 👎.