You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Sentry MCP: get_event_attachment returns an empty body — download fails schema validation, and listing reports SHA1 of the empty string for every attachment #1267
Reproduced on org daniels-sentry-org1 / project javascript-vue-test (EU, https://de.sentry.io),
event 8c365db20f0845c3a71315a943205d83, with two attachments of known content:
File
Size
Actual SHA1
one.log (id 858188125)
540 B
223522016c9ef121e912f2462f7f15e22d6e5399
two.log (id 858188126)
1539 B
972cc32bff5f16e2891303fe8907e0008931fbfc
Send an event with two attachments of different content/size.
List them — omit attachmentId: get_event_attachment(organizationSlug='daniels-sentry-org1', projectSlug='javascript-vue-test', eventId='8c365db20f0845c3a71315a943205d83')
Download one — pass attachmentId='858188125'.
Confirm in the Web UI (Issue → Attachments) that both files download intact.
Reproduces with and without explicit regionUrl, on every attachment, across a client restart + connector reconnect.
Expected Result
Step 3 returns the file content as a valid MCP content block. Step 2 reports each attachment's real, distinct SHA1.
Actual Result
Download fails every content-block union branch:
MCP error -32602: Invalid tools/call result: [{
"code": "invalid_union", "path": ["content", 0],
"errors": [
["type" expected "text", "text" expected string received undefined],
["type" expected "image", "data"/"mimeType" expected string received undefined],
["type" expected "audio", "data"/"mimeType" expected string received undefined],
["name"/"uri" expected string, "type" expected "resource_link"],
["resource": ["_meta" expected record received null,
"text"/"blob" expected string received undefined]]
]}]
text/blob/data are all undefined — the response has no content.
2. Listing reports SHA1 of zero bytes for every attachment:
That value is SHA1 of empty input (printf '' | shasum -a 1). Note Size is correct while the SHA1 is of nothing — so metadata resolves fine but the body is empty by hashing time. Likely one root cause for both symptoms: the fetch yields zero bytes, so the connector hashes an empty buffer and builds a content block with no data. 3. Separate defect — _meta: null: the resource branch also fails with "_meta" expected record, received null, independently of the missing body. Fixing the download may not fix this. Web UI is unaffected — the same attachments download intact, so the stored blobs are fine; the fault is in the connector. Not tenant-specific — originally reported by a customer on a different org; reproduced independently here on a separate org/project with freshly created attachments.
Content-Type is missing from downloads. This is being addressed now and should go out later today. The fix applies to all future attachments.
SHA1 is always of empty bytes. This is a known bug (internal ref FS-327). We were planning to deprecate and remove the SHA1 field from the endpoint. There's already a TODO for removal in Sentry MCP, so I'll remove it now.
The missing body and _meta error from MCP. This seems to be coming from MCP and needs further investigation.
Activity
linear-code commentedon Aug 19, 2026
ENG-8444
MCP-1027
danielsheccoury-sentry commentedon Aug 19, 2026
Ticket link where customer reported the issue first - https://app.intercom.com/a/inbox/onh0p2wm/inbox/admin/10968572/conversation/215475549875325?view=TableFullscreen
getsantry commentedon Aug 19, 2026
Auto-routing to @getsentry/product-owners-issues for triage ⏲️
bllewellynbliro commentedon Aug 24, 2026
Any update on this?
mrduncan commentedon Aug 24, 2026
Hi there, we've triaged this internally the team will take a deeper look shortly.
jan-auer commentedon Aug 25, 2026
There are three distinct bugs here:
Content-Typeis missing from downloads. This is being addressed now and should go out later today. The fix applies to all future attachments._metaerror from MCP. This seems to be coming from MCP and needs further investigation.fix(attachments): stop using attachment SHA1 metadata (#1265)
fix(attachments): prevent worker OOM on large event attachments
fix(attachments): prevent worker OOM on large event attachments
fix(attachments): prevent worker OOM on large event attachments (#1281)