feat(attachments): Require same-envelope delivery

develop-docs/sdk/foundations/envelopes/envelope-items.mdx

@@ -31,7 +31,7 @@ The following constraints apply:
 3. **Logs**: An envelope **MUST** contain at most one envelope item containing logs. SDKs **MAY** mix logs from different traces in the same envelope item. The envelope **MUST NOT** include a [DSC](/sdk/foundations/trace-propagation/dynamic-sampling-context/) header; see [Logs](/sdk/telemetry/logs/#log-envelope-item).
 4. **Metrics**: An envelope **MUST** contain at most one envelope item containing metrics. SDKs **MAY** mix metrics from different traces in the same envelope item. The envelope **MUST NOT** include a [DSC](/sdk/foundations/trace-propagation/dynamic-sampling-context/) header; see [Metrics](/sdk/telemetry/metrics/#trace_metric-envelope-item).
 5. **Sessions**: Multiple envelope items containing sessions **MAY** appear in a single envelope. SDKs **SHOULD** send session updates in the same envelope as their associated error or crash event; see [Sessions](/sdk/telemetry/sessions/#session-update-payload).
-6. **Attachments**: Multiple envelope items containing attachments **MAY** appear in a single envelope. SDKs **SHOULD** send attachments in the same envelope as their associated event, so that if the event is filtered, the attachments are also filtered. For minidump and Apple crash report attachments, this is a **MUST**; see [Attachments](/sdk/telemetry/attachments/#standard-attachments).
+6. **Attachments**: Multiple envelope items containing attachments **MAY** appear in a single envelope. SDKs **MUST** send attachments in the same envelope as their associated event, so that if the event is filtered, the attachments are also filtered.
 7. **Check-ins**: An envelope **MUST** contain at most one envelope item containing a check-in; see [Check-Ins](/sdk/telemetry/check-ins/#envelope-constraints).
 8. **Client reports**: Multiple envelope items containing client reports **MAY** appear in a single envelope; see [Client Reports](/sdk/telemetry/client-reports/#wire-format).
 9. **Replays**: SDKs **MUST** send the `replay_event` and `replay_recording` envelope items together in the same envelope; see [Replay](/sdk/telemetry/replays/#replay-event-payload).

develop-docs/sdk/telemetry/attachments.mdx

@@ -2,12 +2,15 @@
 title: Attachments
 description: File attachments associated with events and traces, including screenshots, minidumps, crash reports, and view hierarchies.
 spec_id: sdk/telemetry/attachments
-spec_version: 1.6.0
+spec_version: 1.7.0
 spec_status: stable
 spec_depends_on:
   - id: sdk/foundations/transport/envelopes
     version: ">=1.0.0"
 spec_changelog:
+  - version: 1.7.0
+    date: 2026-09-08
+    summary: Disallowed sending attachments in separate envelopes
   - version: 1.6.0
     date: 2026-02-24
     summary: Added attachment placeholders for resumable uploads (experimental)
@@ -73,7 +76,7 @@ Attachments are distinguished by the `attachment_type` header on the envelope it
 
 ### Association Model
 
-Standard attachments are associated with an **event** via `event_id`. They can be sent in the same envelope as the event or separately (with caveats around independent dropping).
+Standard attachments are associated with an **event** via `event_id`. They must be sent in the same envelope as the event.
 
 Trace attachments (experimental) are associated with a **trace** via `trace_id` and are optionally linked to specific spans or logs.
 
@@ -91,8 +94,7 @@ Envelope item type `"attachment"`. Contains the raw payload of an attachment fil
 
 - This item **MAY** occur multiple times per envelope.
 - For **minidump** and **apple crash report** attachments, the corresponding `"event"` item **MUST** be sent within the same envelope.
-- Generic attachments can be ingested separately from their events. SDKs **SHOULD** send them in the same envelope, which allows for more efficient rate limiting and filtering.
-- Generic attachments sent in separate envelopes can be dropped independently of an event. To ensure consistent handling, send them in the same request.
+- Generic attachments **MUST** be sent in the same envelope as their corresponding event. This ensures consistent filtering and rate limiting.
 - The Sentry server supports special attachments to ingest event payloads for backwards compatibility. These are not part of the official public API and the behavior **MUST NOT** be relied upon.
 
 </SpecSection>
@@ -180,7 +182,7 @@ Attachment placeholders are an experimental feature, the protocol is subject to
 
 Attachment placeholders use item type `"attachment"` with content type `"application/vnd.sentry.attachment-ref+json"`. A placeholder contains a **reference** to an attachment uploaded elsewhere — it does _not_ contain the actual attachment payload. The purpose is for the attachment to be handled (rate limited, filtered, etc.) together with the event payload, even if it was uploaded separately.
 
-SDKs **SHOULD** send placeholders in the same envelope as the event the file is attached to.
+SDKs **MUST** send placeholders in the same envelope as the event the file is attached to.
 
 **Workflow:**
 
@@ -205,7 +207,7 @@ SDKs **SHOULD** send placeholders in the same envelope as the event the file is
       | ----------------- | ------ | ------------ | -------------------------------------------------------------------|
       | `attachment_type` | String | **REQUIRED** | One of the values listed in [Attachment Types](#attachment-types). |
 
-      
+
    1. Get the location response header:
       ```
       HTTP/1.1 201 Created
@@ -376,6 +378,8 @@ Attachments **SHOULD** offer a flag `addToTransactions` that specifies whether t
 
 ```
 {"event_id":"9ec79c33ec9942ab8353589fcb2e04dc"}
+{"type":"event","length":74}
+{"event_id":"9ec79c33ec9942ab8353589fcb2e04dc","timestamp":1234567890}
 {"type":"attachment","length":12,"filename":"log.txt","content_type":"text/plain"}
 Hello World!
 ```
@@ -394,6 +398,8 @@ Hello World!
 
 ```
 {"event_id":"9ec79c33ec9942ab8353589fcb2e04dc"}
+{"type":"event","length":74}
+{"event_id":"9ec79c33ec9942ab8353589fcb2e04dc","timestamp":1234567890}
 {"type":"attachment","length":245,"filename":"view-hierarchy.json","content_type":"application/json","attachment_type":"event.view_hierarchy"}
 {"rendering_system":"compose","windows":[{"type":"com.example.MyActivity","width":1080,"height":1920,"visible":true,"children":[{"type":"android.widget.TextView","width":200,"height":48,"visible":true}]}]}
 ```
@@ -402,6 +408,8 @@ Hello World!
 
 ```
 {"event_id":"9ec79c33ec9942ab8353589fcb2e04dc"}
+{"type":"event","length":74}
+{"event_id":"9ec79c33ec9942ab8353589fcb2e04dc","timestamp":1234567890}
 {"type":"attachment","content_type":"application/vnd.sentry.attachment-ref+json","length":123,"attachment_length":212341234,"filename":"myfile.log"}
 {"location":"/api/42/upload/019c7a950dd376a1817a9ced5cb7c4b5/?length=212341234&signature=Zct1IMmM3BIJrzDOwG3tUn5AlrLhqIJFBu8Kd59dXCz","content_type":"text/plain"}
 ```

develop-docs/sdk/telemetry/feedbacks.mdx

@@ -2,12 +2,15 @@
 title: Feedback
 description: Collecting qualitative user input with optional attachments, replay links, and error associations.
 spec_id: sdk/telemetry/feedbacks
-spec_version: 1.3.0
+spec_version: 1.4.0
 spec_status: stable
 spec_depends_on:
   - id: sdk/foundations/transport/envelopes
     version: ">=1.0.0"
 spec_changelog:
+  - version: 1.4.0
+    date: 2026-09-08
+    summary: Disallowed sending attachments in separate envelopes
   - version: 1.3.0
     date: 2026-02-04
     summary: Broadened attachments from screenshots-only to any file type, added attachment examples to envelope
@@ -169,7 +172,7 @@ The `contexts.feedback` object carries user-provided feedback data:
 
 ### File Attachments
 
-SDKs **MAY** attach files of any type to a feedback (screenshots, logs, documents, etc.) by sending them as [attachment items](/sdk/telemetry/attachments/), with `event_id` corresponding to the feedback item. SDKs **SHOULD** send attachment items in the same envelope as the feedback item. (since 1.3.0) Attachments are not limited to screenshots — any file type is supported.
+SDKs **MAY** attach files of any type to a feedback (screenshots, logs, documents, etc.) by sending them as [attachment items](/sdk/telemetry/attachments/), with `event_id` corresponding to the feedback item. SDKs **MUST** send attachment items in the same envelope as the feedback item. (since 1.3.0) Attachments are not limited to screenshots — any file type is supported.
 
 </SpecSection>
 

develop-docs/sdk/telemetry/spans/span-protocol.mdx

@@ -252,8 +252,8 @@ Spans missing **Strictly Required** attributes MAY be rejected by Relay.
 All other attributes in the table are required _if_ they are available to the SDK.
 For example, `sentry.release` MUST be sent, if and only if the SDK has a `release` value set (or auto-detected it).
 
-Attributes outside of the above list MUST only be attached to the span they conceptually belong on, and not propagated to children spans. 
-For instance, attributes mirroring transaction context data should only be set on the segment span. 
+Attributes outside of the above list MUST only be attached to the span they conceptually belong on, and not propagated to children spans.
+For instance, attributes mirroring transaction context data should only be set on the segment span.
 See also [the implementation guidelines](/sdk/telemetry/spans/implementation/#how-to-approach-span-first-in-sdks).
 
 Empty attributes MUST be omitted.
@@ -301,7 +301,7 @@ span_id: "438f40bd3b4a41ee"
 Span attachments are an experimental feature that is still under development.
 </Alert>
 
-To associate an attachment with a span, submit a [trace attachment](/sdk/telemetry/attachments/#trace-attachments) item with an additional `span_id` item header. The trace attachment _should_ be submitted in the same envelope as the span itself.
+To associate an attachment with a span, submit a [trace attachment](/sdk/telemetry/attachments/#trace-attachments) item with an additional `span_id` item header. The trace attachment **MUST** be submitted in the same envelope as the span itself.
 
 - `span_id` is the ID of the span that owns the attachment. If set, the attachment will be dropped with the span if the span is dropped by dynamic sampling, inbound filters or rate limits. That is, Relay treats `span_id` as the owner of the attachment.
 - The SDK _may_ set the `span_id` item header to an explicit `null` value. `span_id: null` is treated as “owned by spans”, but not owned by a specific span. That is, the attachment can be dropped if the span quota is exceeded, but it will not be dropped with a specific span because of e.g. inbound filters.