unslothai/unsloth · error · HTTPException

Failed to export LoRA adapter

Error message

Failed to export LoRA adapter

What it means

Generic 500 from the LoRA adapter export endpoint's catch-all. Deliberate failures arrive as (False, message) tuples (→400) and sidecar swaps as 409, so this 500 means an unexpected exception escaped backend.export_lora_adapter or the follow-up _export_details call. The true traceback is logged server-side as 'Error exporting LoRA adapter:' with exc_info.

Source

Thrown at studio/backend/routes/export.py:479

        if not success:
            raise HTTPException(status_code = 400, detail = message)

        return ExportOperationResponse(
            success = True,
            message = message,
            details = await asyncio.to_thread(_export_details, output_path, refresh_index = True),
        )
    except HTTPException:
        raise
    except Exception as e:
        from utils.transformers_version import SidecarSwapInProgress

        if isinstance(e, SidecarSwapInProgress):
            # Expected loss of the race against a sidecar install: retryable 409.
            raise HTTPException(status_code = 409, detail = str(e))
        logger.error(f"Error exporting LoRA adapter: {e}", exc_info = True)
        raise HTTPException(
            status_code = 500,
            detail = "Failed to export LoRA adapter",
        )


# Live export log stream (Server-Sent Events).
#
# The export worker's stdout/stderr is piped to the orchestrator as log
# entries (core/export/worker.py, orchestrator.py); this endpoint streams
# them to the browser for a live terminal panel during export operations.
#
# Shape follows routes/training.py::stream_training_progress: each event
# carries id/event/data, the stream starts with a `retry:` directive, and
# `Last-Event-ID` is honored on reconnect.


def _format_sse(
    data: str,

View on GitHub (pinned to 203007d190)

Solutions

1. Inspect the backend log traceback — it identifies whether serialization, gguf conversion, or the hub push failed.
2. Re-save/reload the PEFT model if the adapter state is corrupt, or retrain briefly to regenerate it.
3. Retry with gguf=false and push_to_hub=false to isolate which stage fails.
4. Validate hf_token before export when pushing.

Example fix

# before
resp = client.post('/api/export/lora', json={'gguf': True})
# 500 'Failed to export LoRA adapter'

# after
resp = client.post('/api/export/lora', json={'gguf': False})  # isolate the failure
# check backend log; re-enable gguf only if conversion tooling is present

try { await exportLora(body); }
catch (e) { if (e.status === 500) { captureBackendTraceback(); notify('LoRA export crashed — see backend log'); } }

When it happens

Trigger: POST /export/lora where adapter serialization crashes (corrupt PEFT state, disk full writing adapter_model.safetensors), gguf conversion of the adapter fails unexpectedly (request.gguf=true), or the hub push raises from network/auth errors.

Common situations: Exporting an adapter whose training process crashed midway, requesting GGUF conversion of the adapter without the conversion toolchain present, or an expired hf_token raising inside the push path instead of returning a failure tuple.

Related errors

• Failed to load checkpoint
• Memory cleanup failed. See server logs for details.
• Failed to cleanup export memory
• Failed to cancel export
• Failed to get export status

AI-assisted analysis of unslothai/unsloth@203007d190 (2026-08-15). Data as JSON: /api/errors/84a2dabcedb8ae17. Report an issue: GitHub.