Description

Simon Biwer (simonbiwer)

opened on Jul 22, 2026

Issue body actions

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_

Reacted by Iñigo Hidalgo

Activity

1. Simon Biwer (simonbiwer)

   added

   status:waiting-for-triageAn issue that is yet to be reviewed or assignedAn issue that is yet to be reviewed or assigned

   type:bugA broken experienceA broken experience

   on Jul 22, 2026
2. inigohidalgo commented on Jul 22, 2026

   

   Iñigo Hidalgo (inigohidalgo)

   on Jul 22, 2026

   More actions

   The <=1.58.0 boundary is misleading — this isn't an msgraph-sdk change.

   It's the transitive dep: microsoft-kiota-serialization-json 1.11.6 → 1.11.7, released 2026-06-30, which changed JsonParseNode._get_bytes_value to base64-decode:

   # <=1.11.6                                # 1.11.7
   return base64_string.encode("utf-8")      return base64.b64decode(value)

   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 .xlsx attachments 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 pinning microsoft-kiota-serialization-json>=1.11.7 directly instead of inheriting the msgraph-sdk range.

   Reacted by Simon Biwer

Issue actions