What causes "checked for name previously" in seanmonstar/warp?

Prefer `part.filename()` or the underlying optional accessors when you cannot guarantee the part has a name

checked for name previously

Error message

checked for name previously

What it means

`warp::multipart::Part::name()` returns the part's form field name, falling back to `file_name().expect("checked for name previously")` (src/filters/multipart.rs:143). The expect assumes that whenever `name()` is absent, `file_name()` is present — an invariant from the underlying multipart parsing. If the invariant breaks (a part has neither a name nor a filename), this panics with an internal-invariant message rather than returning a value.

Solutions

Prefer `part.filename()` or the underlying optional accessors when you cannot guarantee the part has a name
Validate Content-Disposition on the client side so every form field includes a name attribute
If hit in practice, treat the request as malformed and reject it before touching `name()`
Guard in your handler: check filename() first, then fall back to a synthetic name instead of calling name() blindly

Example fix

// before
let field_name = part.name().to_string();
// after
let field_name = part.filename()
    .map(|f| f.to_string())
    .unwrap_or_else(|| "unnamed-part".to_string());

Defensive patterns

Strategy: fallback

Validate before calling

// check before relying on name():
let label = part.filename().map(str::to_owned).unwrap_or_else(|| "<unnamed>".into());

Try / catch

// cannot catch a panic in sync code here; avoid by using optional accessors:
let name = part.filename().map(|f| f.to_string())
    .unwrap_or_else(|| format!("part-{}", index));

Prevention

Treat multipart parts as optionally-named; don't assume name() always succeeds
Reject malformed multipart requests early in the filter chain
Test with hand-crafted Content-Disposition headers lacking name/filename
Prefer filename() or the underlying library's optional getters in generic handlers

When it happens

Trigger: Calling `part.name()` on a multipart part whose underlying `Part` has neither a `name` disposition param nor a `filename` param — e.g. hand-crafted or malformed multipart bodies where the Content-Disposition lacks both.

Common situations: Proxies or clients sending multipart bodies with `Content-Disposition: form-data` and no name/filename; fuzzed or malformed uploads; older/odd clients that omit the name attribute on file fields.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

AI-assisted analysis of seanmonstar/warp@ff34d7213e (2026-09-09). Data as JSON: /api/errors/004b597fb679cefd. Report an issue: GitHub.

Appendix: source

Thrown at src/filters/multipart.rs:143

                    Poll::Ready(Some(Ok(Part { part })))
                } else {
                    Poll::Ready(Some(Err(crate::Error::new(MultipartFieldMissingName))))
                }
            }
            Poll::Ready(Ok(None)) => Poll::Ready(None),
            Poll::Ready(Err(err)) => Poll::Ready(Some(Err(crate::Error::new(err)))),
        }
    }
}

// ===== impl Part =====

impl Part {
    /// Get the name of this part.
    pub fn name(&self) -> &str {
        self.part
            .name()
            .unwrap_or_else(|| self.part.file_name().expect("checked for name previously"))
    }

    /// Get the filename of this part, if present.
    pub fn filename(&self) -> Option<&str> {
        self.part.file_name()
    }

    /// Get the content-type of this part, if present.
    pub fn content_type(&self) -> Option<&str> {
        let content_type = self.part.content_type();
        content_type.map(|t| t.as_ref())
    }

    /// Asynchronously get some of the data for this `Part`.
    pub async fn data(&mut self) -> Option<Result<impl Buf, crate::Error>> {
        future::poll_fn(|cx| self.poll_next(cx)).await
    }

View on GitHub (pinned to ff34d7213e)