redirect_panic.md

redirect_storage panics (PanicException, not IcechunkError) resolving an http+icechunk:// Location

Following the storage guide's Redirect Storage section: a 302 whose Location uses the documented http+icechunk:// scheme causes a Rust panic that escapes to Python as pyo3_runtime.PanicException rather than an IcechunkError.

Reprex:

import http.server, threading, icechunk as ic

class H(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(302)
        self.send_header("Location", "http+icechunk://example.com/nothing")
        self.end_headers()

srv = http.server.ThreadingHTTPServer(("127.0.0.1", 0), H)
threading.Thread(target=srv.serve_forever, daemon=True).start()
ic.Repository.open(ic.redirect_storage(f"http://127.0.0.1:{srv.server_address[1]}/x"))

thread '<unnamed>' panicked at icechunk/src/storage/redirect.rs:218:22:
Internal error, cannot set url scheme: ()
pyo3_runtime.PanicException: Internal error, cannot set url scheme: ()

Possible cause: url::Url::set_scheme refuses conversions between "special" and non-special schemes - http+icechunk:// is non-special, http is special, so stripping the tag via set_scheme("http") returns Err(()) unconditionally, and line 218 appears to unwrap it. If so, the http(s)+icechunk:// path may never succeed as written; rebuilding the URL from parts (rather than set_scheme) is the usual workaround for this url-crate restriction.

Two adjacent observations: (1) the same tagged scheme passed directly to redirect_storage() fails gracefully ("builder error for url ..."), so only the redirect-resolution path is affected; (2) a plain http:// Location is silently consumed by the HTTP client's auto-follow and surfaces as "response must be a redirect" — correct per the documented limitations, but the error might usefully hint at the +icechunk scheme tag, since a plain-http Location is the natural first attempt.

Encountered while testing a locally hosted repo (icechunk 2.1.0, Python 3.12.3, Linux).