hermes - 💡(How to fix) Fix [BUG] unhandled auth_type oauth_minimax warning on auxiliary providers

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Every time a chat session starts (new conversation or /new), the errors.log shows:

WARNING agent.auxiliary_client: resolve_provider_client: unhandled auth_type oauth_minimax for minimax-oauth

This fires twice per session (once per auxiliary client initialization).

Root Cause

In agent/auxiliary_client.py, the resolve_provider_client() function handles auth_type values like bearer, api_key, oauth_openai, but has no handler for oauth_minimax:

# File: agent/auxiliary_client.py
def resolve_provider_client(provider, auth_type, ...):
    if auth_type == "bearer": ...
    elif auth_type == "api_key": ...
    elif auth_type == "oauth_openai": ...
    # ← no elif for "oauth_minimax"
    else:
        logger.warning("unhandled auth_type %r for %r", auth_type, provider)
        return None  # ← falls back, chat still works

Code Example

WARNING agent.auxiliary_client: resolve_provider_client: unhandled auth_type oauth_minimax for minimax-oauth

---

# File: agent/auxiliary_client.py
def resolve_provider_client(provider, auth_type, ...):
    if auth_type == "bearer": ...
    elif auth_type == "api_key": ...
    elif auth_type == "oauth_openai": ...
    # ← no elif for "oauth_minimax"
    else:
        logger.warning("unhandled auth_type %r for %r", auth_type, provider)
        return None  # ← falls back, chat still works
RAW_BUFFERClick to expand / collapse

Description

Every time a chat session starts (new conversation or /new), the errors.log shows:

WARNING agent.auxiliary_client: resolve_provider_client: unhandled auth_type oauth_minimax for minimax-oauth

This fires twice per session (once per auxiliary client initialization).

Impact

  • Non-critical: chat works correctly via fallback
  • Logs are polluted (145+ warnings accumulated in a few hours)
  • Affects all profiles (default, finus, tikita) when using minimax-oauth

Root Cause

In agent/auxiliary_client.py, the resolve_provider_client() function handles auth_type values like bearer, api_key, oauth_openai, but has no handler for oauth_minimax:

# File: agent/auxiliary_client.py
def resolve_provider_client(provider, auth_type, ...):
    if auth_type == "bearer": ...
    elif auth_type == "api_key": ...
    elif auth_type == "oauth_openai": ...
    # ← no elif for "oauth_minimax"
    else:
        logger.warning("unhandled auth_type %r for %r", auth_type, provider)
        return None  # ← falls back, chat still works

Suggested Fix

Add a handler branch for auth_type == "oauth_minimax". The logic should mirror the oauth_openai handler since both are OAuth-based. Alternatively, extract a shared _resolve_oauth_client() helper.

Environment

  • Hermes Agent: latest (NousResearch/hermes-agent)
  • Profiles: default, finus, tikita
  • Provider: minimax-oauth
  • OS: Debian GNU/Linux 13 (trixie) VM

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING