[lisry-1]

Motivation & Context

With encoding_format="base64", both embedding clients call base64.b64decode on each payload before unpacking it as little-endian float32 values. A payload that cannot be decoded at all escapes as a bare binascii.Error (bad padding/alphabet) or UnicodeEncodeError (non-ASCII input that str.encode("ascii") rejects), with no reference to the input that broke — so a malformed response is indistinguishable from a bug in the client.

Reported in #9511.

Relationship to #9512

#9512 (merged) already reports a misaligned payload — one whose decoded length is not a multiple of 4 — for the OpenAI client. This PR deliberately scopes itself to the remaining, still-unhandled path: a payload that cannot be decoded at all. It adds that path to the OpenAI client, and adds both guards to the Foundry client (which #9512 did not touch).

Description & Review Guide

• What are the major changes?

  python/packages/openai/agent_framework_openai/_embedding_client.py and python/packages/foundry/agent_framework_foundry/_embedding_client.py:

  • base64.b64decode is wrapped in except ValueError (the common base of binascii.Error and UnicodeEncodeError) and re-raised as IntegrationInvalidResponseException, naming the input index and preserving the original cause.
  • The Foundry client had neither guard, so it also gains the misaligned-length check (Python: reject misaligned base64 embedding payloads with a descriptive error #9512's behaviour) for parity.

  Well-formed payloads are unaffected; the guard only rejects input that would have failed during b64decode or struct.unpack anyway.

• What is the impact of these changes?

  Callers that previously caught binascii.Error / UnicodeEncodeError now see IntegrationInvalidResponseException, the public agent_framework.exceptions type used for invalid integration responses.

• What do you want reviewers to focus on?

  The exception type. IntegrationInvalidResponseException is the closest match in the existing hierarchy for "the service returned something we cannot interpret".

Related Issue

Fixes #9511

Contribution Checklist

• The code builds clean without any errors/warnings
• New tests were added for the change
• Regression verified: each new test fails without the fix
• No unrelated changes included
• Rebases cleanly onto main after Python: reject misaligned base64 embedding payloads with a descriptive error #9512 landed

AI Assistance

• An AI coding assistant helped locate the defect, draft the fix, and write the tests.
• I understand and reviewed every change in this pull request.
• The reproduction and all tests were run locally.

Test runs (after rebase onto main): test_openai_embedding_client.py 22 passed / 3 skipped; test_foundry_embedding_client.py 32 passed / 2 skipped.

[Copilot]

🟡 Changes recommended

Non-ASCII payloads still escape both handlers as unannotated ValueError exceptions, and Foundry’s decode-error handler lacks regression coverage.

2 open issues

• Add regression test for undecodable embedding payloads · New
• Wrap ValueError from non-ASCII embedding decoding · New

What changed in this PR

This PR addresses #9511 by giving malformed base64 embedding responses contextual framework errors in the Python OpenAI and Foundry integrations.

Changes:

• Wraps base64 decoding errors in IntegrationInvalidResponseException.
• Rejects decoded lengths that are not divisible by four, reporting the input index and byte count.
• Adds regression tests for malformed payloads.

File	Description
python/​packages/​openai/​tests/​openai/​test_openai_embedding_client.py	Tests invalid decoded lengths and undecodable payloads.
python/​packages/​openai/​agent_framework_openai/​_embedding_client.py	Adds contextual errors around base64 decoding and length validation.
python/​packages/​foundry/​tests/​foundry/​test_foundry_embedding_client.py	Tests invalid decoded lengths in project mode.
python/​packages/​foundry/​agent_framework_foundry/​_embedding_client.py	Adds equivalent validation using original input indices.

_{Review effort: Balanced}

[Eduard van Valkenburg (eavanvalkenburg)]

lisry-1 Thanks for clarifying the scope relative to #9512. This is an agreed follow-up to #9511: the remaining undecodable-payload handling and Foundry parity are in scope. IntegrationInvalidResponseException is acceptable for these new guards; the existing OpenAI misaligned-length ValueError can stay unchanged in this PR.