In `allure-java`, what does an attachment's `type` decide, and what changes when a test attaches its payload as `AttachmentType.OCTET_STREAM`?
answer
- type is a media type
- constants, not an enum
- it names the file too
- octet-stream carries an empty extension
- no extension, no preview
basics
~20 sThe type is the payload's media type, and it decides two things: the extension the writer appends to the payload file, and whether the report can preview the content. OCTET_STREAM contributes no extension and no preview.
solid answer
~40 s`AttachmentType` is a final class of constants, not an enum, and each constant pairs a media type with a file extension — `PNG` is `image/png` plus `png`, `TEXT` is `text/plain` plus `txt`, `WEBM` is `video/webm` plus `webm` — reachable through `getMediaType()` and `getExtension()`. The media type goes into the entry's `type`, and the extension is what the writer appends after `-attachment` when the caller gave no extension of its own. `OCTET_STREAM` is the deliberate odd one out: its media type is `application/octet-stream` and **its extension is the empty string**, so the payload file's name ends at `-attachment` with nothing after it. Downstream, `application/octet-stream` says only "some bytes", so the report has nothing to render with and offers the file for download instead of showing it inline.
code
java · 10 linesAllure.attachment(
"Server log",
AttachmentType.TEXT.getMediaType(),
"connection refused after three retries");
Allure.attachment(
"Heap dump",
AttachmentType.OCTET_STREAM.getMediaType(),
new ByteArrayInputStream(dumpBytes),
AttachmentOptions.empty());go deeper
Know that type is a media type like image/png or text/plain, and that declaring it accurately is what lets the report show a screenshot as a picture rather than as a file to download.
Explain both jobs the type does — deriving the payload file's extension and driving how the report renders it — and say why OCTET_STREAM, with its empty extension, produces a file whose name ends at -attachment.
Show you know a wrong type fails silently: nothing validates the declaration against the bytes, so a mislabelled payload is written under a misleading extension and handed to a renderer that cannot decode it.
Be able to set a convention for what a suite declares — specific types by default, the opaque fallback only for genuinely unreadable payloads — and explain how that choice changes what a reader can do without leaving the report.
## What `type` actually is The `type` on an attachment is a **media type** — the same `image/png` or `text/plain` string an HTTP server would put in a `Content-Type` header. It is not a category the report invented; it is the one piece of metadata that tells every downstream consumer what the opaque bytes in the payload file are. `allure-java` ships a set of ready-made ones in `AttachmentType`. The shape of that class is worth noticing, because people describe it wrongly: **it is a `final class` of `public static final` constants with a private constructor, not an enum.** Each constant is a pair, and both halves are readable: - `getMediaType()` returns the media type string. - `getExtension()` returns the file extension that goes with it. | constant | media type | extension | |---|---|---| | `PNG` | `image/png` | `png` | | `JPEG` | `image/jpeg` | `jpg` | | `TEXT` | `text/plain` | `txt` | | `HTML` | `text/html` | `html` | | `ZIP` | `application/zip` | `zip` | | `WEBM` | `video/webm` | `webm` | | `OCTET_STREAM` | `application/octet-stream` | *(empty)* | Because it is a class and not an enum, the set is open in practice: a media type is just a string, and a tool that needs a vendor-specific one can declare it. `PLAYWRIGHT_TRACE`, for instance, carries its own vendor media type while reusing the `zip` extension, because that is what the payload physically is. ## The two jobs `type` does 1. **It names the file.** When a test attaches without supplying its own file extension, the writer maps the declared media type to a well-known extension and appends it to the payload file name, after the UUID and the `-attachment` suffix. `image/png` therefore yields a file ending `.png`. 2. **It decides what the report can do with the bytes.** The generated report keys its rendering off the media type: an image type gets an inline preview, a text type gets a text view, and anything the report cannot render is offered as a download. Those two jobs are the whole reason a wrong `type` is worse than a missing label. A log attached as `image/png` is not merely mislabelled — it is written to a file called `…-attachment.png` and then handed to an image renderer that cannot decode it. ## Why `OCTET_STREAM` is the interesting one `application/octet-stream` is the media-type world's shrug. It is the registered way of saying "an unspecified stream of bytes", and `AttachmentType.OCTET_STREAM` carries it with a deliberately **empty** extension. Two things follow directly: - **The payload file gets no extension.** The writer normalises the extension by prefixing a dot only when there is something to prefix; an empty extension normalises to the empty string, so the file name stops at `-attachment`. That is exactly why the glob for payload files needs a trailing wildcard: some payload files genuinely have nothing after the suffix. - **The report cannot preview it.** With no more specific type to dispatch on, there is nothing to render inline; the reader is given the bytes to download and left to work out what they are. So `OCTET_STREAM` is the right choice for a genuinely opaque payload — a heap dump, a proprietary capture format, a binary blob whose only useful action is "save it and open it in the tool that understands it". It is the wrong choice as a lazy default, because it strips both the file extension and the preview from something the report could otherwise have shown. ## Common ways this goes wrong - **Attaching text as bytes.** A log attached as `OCTET_STREAM` becomes an extensionless download that nobody opens. Attached as `text/plain`, the same bytes are readable inside the report without leaving the page — which is usually the entire point of attaching a log. - **Trusting a guessed type.** Some producers infer the type from the file suffix, which is a guess about a guess. Declare the type explicitly when you know it. - **Assuming the type is cosmetic.** It is not; it participates in naming the file on disk. - **Assuming the declared type must match the bytes.** Nothing enforces it. The declared value is taken at face value and used for both naming and rendering, so a mismatch is silent and shows up only as a preview that will not render. ## How to choose The practical rule is to declare the **most specific media type that is honestly true of the bytes**. Specific types cost nothing and buy an extension and a preview. Fall back to `OCTET_STREAM` only when no more specific type applies, and expect the report to treat that payload as something to download rather than something to read.
- A test attaches a JSON body but declares it as `text/plain`. What does that cost, and what does it not break?Nothing breaks: the bytes are written faithfully and the report shows them as text. What it costs is presentation — a viewer keyed to a JSON media type could pretty-print or fold the document, and a plain-text declaration forfeits that. The payload file also picks up a `.txt` extension rather than a JSON one.
- Why does the glob used to find payload files need a wildcard after `-attachment` rather than a fixed extension?Because the extension is optional. It is derived from the declared media type or supplied by the caller, and when neither yields anything — `OCTET_STREAM` being the built-in example, since its extension is empty — the file name ends at `-attachment`. A glob demanding a dot would miss exactly those payloads.
saying these in an interview costs you the question
- Calls AttachmentType an enum of fixed values
- Says the type only affects how it displays
- Thinks octet-stream gives files a .bin extension
- Assumes the declared type is validated against the bytes