(WIP) Support 413 handling

[Radhika Gupta (rads-1996)]

Description

Add support to handle the 413 payload too large status code, in alignment with spec.

All SDK Contribution checklist:

• The pull request does not introduce [breaking changes]
• CHANGELOG is updated for new features, bug fixes or other significant changes.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
9 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Adds HTTP 413 handling to the Azure Monitor OpenTelemetry exporter.

Changes:

• Splits oversized batches and persists sub-batches for retry.
• Avoids logging oversized telemetry payloads.
• Adds tests, a reproduction sample, and release notes.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
export/_base.py	Implements payload sizing, splitting, persistence, and safer logging.
tests/test_base_exporter.py	Tests 413 handling and payload splitting.
sample_test_413.py	Adds a manual 413 reproduction script.
CHANGELOG.md	Documents the feature.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (3)

sdk/monitor/azure-monitor-opentelemetry-exporter/azure/monitor/opentelemetry/exporter/export/_base.py:346

• The 413 contract requires splitting and resending down to individual items, but this branch drops the entire batch whenever offline storage is disabled. Users who opt out of persistence therefore receive none of the spec-aligned 413 handling described by this PR. Split/retry in memory regardless of storage availability, using persistence only as a fallback.

        if not self.storage:
            if not self._is_stats_exporter():
                logger.debug(
                    "Payload too large but offline storage is disabled; dropping %d envelope(s): %s.",
                    len(envelopes),
                    response_error.message,
                )
                if self._should_collect_customer_sdkstats():
                    track_dropped_items(envelopes, DropCode.CLIENT_STORAGE_DISABLED)
            return ExportResult.FAILED_NOT_RETRYABLE

sdk/monitor/azure-monitor-opentelemetry-exporter/CHANGELOG.md:22

• This feature is introduced in the unreleased 1.0.0b57 section above, but these duplicate notes place it in the already released 1.0.0b56 history (2026-08-06), incorrectly implying that published version contains the new behavior. Remove this entry from the historical release.

- Handle `413 Payload Too Large` responses by splitting the batch and persisting each half to
  local storage for retry at a smaller size, instead of dropping the entire batch. A single
  envelope that is too large to split is dropped.

sdk/monitor/azure-monitor-opentelemetry-exporter/azure/monitor/opentelemetry/exporter/export/_base.py:359

• When a 413 occurs while draining storage, the original blob remains on disk until _transmit returns (_transmit_from_storage lines 294–302), while this line writes the split copies immediately. With the default 50 MiB cap, a large original can consume enough capacity that only the first split is persisted; the later split is dropped, and then the original is deleted, permanently losing telemetry. Replace the original without temporarily duplicating its contents (or resend the splits directly), and cover a 413 encountered during storage drain.

            result_from_storage_put = self.storage.put([x.as_dict() for x in sub_batch])