Repository navigation
FileAttachment.content_bytes does not return b64-encoded content. #1556
Description
Describe the bug
On attempt to b64decode the content_bytes of a file attachment the following error occurs:
binascii.Error: Only base64 data is allowed
The same test provided below passes with msgraph-sdk <= 1.58.0
The code comments still suggest b64-encoded content:
# The base64-encoded contents of the file. content_bytes: Optional[bytes] = None
Expected behavior
FileAttachment.content_bytes returns b64-encoded data.
How to reproduce
from base64 import b64decode
from typing import cast
from azure.core.credentials import TokenCredential
from azure.identity import ClientSecretCredential
from msgraph import GraphServiceClient
from msgraph.generated.models.attachment import Attachment
from msgraph.generated.models.file_attachment import FileAttachment
from settings import settings
credentials = cast(
TokenCredential,
ClientSecretCredential(
tenant_id=settings().microsoft_graph_tenant_id,
client_id=settings().microsoft_graph_client_id,
client_secret=settings().microsoft_graph_client_secret,
),
)
scopes = ["https://graph.microsoft.com/.default"]
client = GraphServiceClient(credentials, scopes)
async def get_mail_attachments(
mailbox: str, mail_id: str
) -> list[Attachment]:
response = (
await client.users.by_user_id(mailbox)
.messages.by_message_id(mail_id)
.attachments.get()
)
attachments: list[Attachment] = response.value or []
return attachments
async def test_attachments():
attachments = await get_mail_attachments("my-mailbox", "my-mail-id")
assert len(attachments) >= 1
first_attachment = attachments[0]
assert isinstance(first_attachment, FileAttachment)
b64decode(first_attachment.content_bytes, validate=True)
SDK Version
1.60.0
Latest version known to work for scenario above?
1.58.0
Known Workarounds
No response
Debug output
Click to expand log
```</details>
### Configuration
_No response_
### Other information
_No response_
Activity
inigohidalgo commentedon Jul 22, 2026
The
<=1.58.0boundary is misleading — this isn't an msgraph-sdk change.It's the transitive dep:
microsoft-kiota-serialization-json1.11.6 → 1.11.7, released 2026-06-30, which changedJsonParseNode._get_bytes_valueto base64-decode:Deliberate — microsoft/kiota-python#646, fixing microsoft/kiota-python#636 (reader was asymmetric with
write_bytes_value).1.58.0, 1.59.2 and 1.60.0 all declare
microsoft-kiota-serialization-json >=1.8.0,<2.0.0, so 1.58.0 installed fresh today picks up 1.11.7 and reproduces this. If it still works for you, something is holding kiota at <=1.11.6.Also worth knowing it doesn't always raise.
b64decode(validate=False)drops non-alphabet bytes and stops at the first=, so if the padding lands valid you get a short garbage blob back instead of an error. Our.xlsxattachments came through as ~110 bytes instead of ~9KB with no exception — only caught later when the parser said "File is not a zip file".Workaround was dropping our own
b64decode()and pinningmicrosoft-kiota-serialization-json>=1.11.7directly instead of inheriting the msgraph-sdk range.