apache/seatunnel · error · RuntimeError

Bedrock Mantle response ended with status

Error message

Bedrock Mantle response ended with status '{status}'{detail}

What it means

The Bedrock Mantle provider inspects the final streaming/response status and treats any terminal non-success status (e.g. 'incomplete', 'failed') as a fatal condition, raising RuntimeError with the status plus any incomplete_details.reason or error.message returned by the API.

Solutions

Read the status and detail in the message: fix the underlying cause reported by incomplete_details or error.message
If the reason is a content/length limit, reduce prompt size or adjust max output tokens and retry
Check AWS Bedrock service health/quota and region configuration (AWS_REGION), then retry the request
Upgrade the aws-bedrock-token-generator/openai packages if the API response shape changed

Example fix

// before
resp = provider.chat(messages)  # RuntimeError: status 'incomplete'
// after
resp = provider.chat(messages, max_tokens=2048)  # fit within limits; inspect resp status

Defensive patterns

Strategy: retry

Validate before calling

# Check status before consuming output
terminal = getattr(response, 'status', None)
if terminal in ('incomplete', 'failed'):
    handle_mantle_failure(response)

Try / catch

try:
    resp = provider.chat(messages)
except RuntimeError as e:
    # e.g. status 'incomplete' with incomplete_details.reason
    log.warning('Mantle run ended badly: %s', e)
    resp = retry_with_smaller_prompt(messages)

Prevention

Keep prompts and max output tokens within service limits
Set AWS_REGION correctly for your Bedrock endpoint
Inspect incomplete_details.reason and error.message early in development
Add retry with backoff for transient service-side failures

When it happens

Trigger: _raise_on_terminal_status (invoked from chat and chat_stream) receives a response whose terminal status is not successful — the Mantle run ended with status like 'incomplete' or 'failed', optionally with incomplete_details or an error object.

Common situations: Response hit a content/length filter (incomplete_details.reason) causing truncation; upstream Bedrock error returned an error payload; long streaming run terminated early by service-side limits.

Understand the failure class

Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.

Related errors

AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/442f2d9862f0f23d. Report an issue: GitHub.

Appendix: source

Thrown at seatunnel-cli/seatunnel_cli/llm_provider.py:1098

    def _raise_on_terminal_status(response) -> None:
        """Fail loudly on non-completed terminal states.

        Bedrock Mantle reports truncation/filtering/model errors in-band via
        ``status`` + ``incomplete_details``/``error`` rather than transport
        errors; treating those as success would hand truncated configs to
        the agent loop as if they were complete.
        """
        status = getattr(response, "status", None)
        if status in (None, "completed"):
            return
        detail = ""
        incomplete = getattr(response, "incomplete_details", None)
        if incomplete is not None:
            detail = f" ({getattr(incomplete, 'reason', '') or incomplete})"
        error = getattr(response, "error", None)
        if error is not None:
            detail += f" error: {getattr(error, 'message', '') or error}"
        raise RuntimeError(
            f"Bedrock Mantle response ended with status '{status}'{detail}")

    def chat(
        self,
        messages: list[dict],
        system: str = "",
        model: str | None = None,
        temperature: float = 0.3,
        max_tokens: int = 4096,
        tools: list[dict] | None = None,
    ) -> dict:
        """Send a non-streaming Responses API request.

        Requests are sent with ``store=False`` so Bedrock does not retain
        prompt/response data server-side (its default is 30-day retention).
        Reasoning output items are preserved verbatim in the returned
        history so subsequent turns can replay them. Non-``completed``
        terminal statuses and refusals raise ``RuntimeError`` instead of

View on GitHub (pinned to cf67b549a7)