Harden iFlow proxy requests to match CLI behavior by redzrush101 · Pull Request #142 · Mirrowel/LLM-API-Key-Proxy

redzrush101 · 2026-02-26T21:09:27Z

Summary

Port iFlow CLI-style anti-block request behavior into the iFlow provider used by LLM-API-Key-Proxy.
Add signed-header handling with a one-shot 406 retry without signature plus upstream API base fallback support.
Fix env-based OAuth credential loading/refresh handling and include glm-5 in iFlow hardcoded models.

Validation

Ran compile checks for modified provider files.
Started proxy with OAuth creds provided via environment variables from oauth_creds.json mapping.
Verified streaming calls through proxy endpoint for iflow/glm-5 and iflow/kimi-k2.5.

Important

Enhance iFlow proxy requests to match CLI behavior with improved signed-header handling, OAuth credential management, and API base fallback support.

Behavior:
- Port CLI-style anti-block request behavior into iFlow provider in iflow_provider.py.
- Add signed-header handling with a one-shot 406 retry without signature and upstream API base fallback.
- Fix OAuth credential loading/refresh from environment variables in iflow_auth_base.py.
Models:
- Include glm-5 in hardcoded models in iflow_provider.py.
Functions:
- Add get_api_base_candidates() and get_api_base() in iflow_auth_base.py for API base URL management.
- Modify _refresh_token() in iflow_auth_base.py to handle env-loaded credentials without file IO.
- Update get_api_details() in iflow_auth_base.py to support env-based credentials.
- Enhance _build_iflow_headers() in iflow_provider.py to include optional signature headers.
- Implement _should_fallback_base() in iflow_provider.py for handling specific HTTP status codes.
Misc:
- Verify streaming calls for iflow/glm-5 and iflow/kimi-k2.5 through proxy endpoint.

^{This description was created by}^{for 97e1449. You can customize this summary. It will automatically update as commits are pushed.}

Add signed-header fallback and base-url failover while fixing env OAuth credential loading/refresh so proxy calls are less likely to get blocked.

Mirrowel · 2026-02-27T00:42:26Z

Gotta give it a couple of days to verify

Resolve conflicts in iFlow provider by preserving existing retry/context-failure handling while integrating PR Mirrowel#142 signed-header fallback and base URL failover logic.

redzrush101 · 2026-02-27T08:54:11Z

Gotta give it a couple of days to verify

ye good

Consolidate follow-up fixes after initial hardening: add captured-header parity and metadata propagation, preserve usage details, introduce sticky session/conversation IDs, and fix reasoning regressions by removing forced disabled-thinking defaults while enabling thinking by default.

…ication Include httpx.RemoteProtocolError in the error type tuple for api_connection classification. This error occurs when a peer closes the connection without sending a complete message and should be treated as a transient connection issue rather than an unhandled exception.

…handler Wrap stream_handler in a retry loop with exponential backoff for transient connection errors (RemoteProtocolError, ConnectError, ReadTimeout, NetworkError). Retries up to 3 times with 1s/2s/4s backoff before re-raising for higher-level error handling. Changes: - Add CONNECTION_ERROR_TYPES tuple and CONTEXT_WINDOW_ERROR_PATTERNS as module-level constants for reuse and clarity - Add MAX_CONNECTION_RETRIES and RETRY_BACKOFF_BASE configuration - Restructure stream_handler with while-loop retry around the stream context manager, re-creating the stream on each retry attempt - Add context window error detection from HTTP error response bodies to surface token limit issues explicitly - Import asyncio for async sleep during backoff

- Detect empty choices array in HTTP 200 responses - Detect zero completion_tokens with non-zero prompt_tokens - Detect empty assistant messages (no content/reasoning/tool_calls) - Detect streams that complete without any data chunks - Raise non-retryable context_window_exceeded error for these cases - Prevents quota waste from repeated failed requests

Mirrowel · 2026-03-03T01:47:14Z

@redzrush101 Integrate #130 please, by adding minimax and anything else so this can be merged.
Don't need the garbage models like qwen 32B or tstars

Also, is #139 integrated? And #136?

mirrobot-agent · 2026-03-03T03:20:40Z

Starting my review of the iFlow proxy hardening PR. Diving into the anti-block request behavior, OAuth handling, and sticky session implementation now.

mirrobot-agent

Overall Assessment

This is a solid PR that significantly hardens the iFlow provider with CLI-matching anti-block behavior, improved OAuth handling, and robust fallback mechanisms. The changes are well-structured and address real-world reliability concerns.

Architectural Feedback

The approach of matching CLI behavior is sound. A few areas worth addressing:

Async compatibility: The sticky session cache uses threading.Lock() in async context
Security: Token exposure in query params
Reliability: Retry logic could benefit from jitter

Key Suggestions

Line 202 in iflow_provider.py: Replace threading.Lock() with asyncio.Lock() to prevent event loop blocking
Line 655 in iflow_auth_base.py: Remove accessToken from query params (headers-only is more secure)
Line 1763 in iflow_provider.py: Add jitter to exponential backoff
Line 1472 in iflow_provider.py: Add clarifying comment about the fake request/response pattern

Nitpicks and Minor Points

The in-place mutation in _inject_iflow_metadata_from_incoming_headers could use documentation
The __del__ cleanup pattern in transaction logger is unreliable; consider explicit cleanup or context managers

Questions for the Author

Was the dual token placement (headers + query params) intentional for compatibility reasons, or an oversight?
Any specific reason for choosing threading.Lock() over asyncio.Lock() for the sticky cache?

This review was generated by an AI assistant.

mirrobot-agent · 2026-03-03T03:28:39Z

src/proxy_app/main.py

            )


+def _inject_iflow_metadata_from_incoming_headers(


The function _inject_iflow_metadata_from_incoming_headers modifies request_data in-place. Consider documenting this side effect in the docstring to make the mutation explicit.

mirrobot-agent · 2026-03-03T03:28:39Z

src/rotator_library/providers/iflow_provider.py

+                )
+            ),
+        )
+        self._sticky_lock = threading.Lock()


The sticky session cache uses threading.Lock() in an async context (called from make_request which is async). This could block the event loop during lock contention. Consider using asyncio.Lock() instead for proper async compatibility.

mirrobot-agent · 2026-03-03T03:28:39Z

src/rotator_library/providers/iflow_provider.py

+            return {k: v for k, v in message.__dict__.items() if not k.startswith("_")}
+        return {}
+
+    def _raise_silent_context_failure(


The _raise_silent_context_failure method creates a fake httpx request/response to raise HTTPStatusError. This is clever but could be confusing. Consider adding a comment explaining why this pattern is used instead of a custom exception.

mirrobot-agent · 2026-03-03T03:28:39Z

src/rotator_library/providers/iflow_provider.py

+                            cause=e,
+                        )
+
+                    backoff = RETRY_BACKOFF_BASE * (2 ** (connection_retry_count - 1))


The connection retry logic uses exponential backoff but doesn't implement jitter. Consider adding random jitter (e.g., backoff * (0.5 + random.random())) to prevent thundering herd when multiple requests retry simultaneously.

mirrobot-agent · 2026-03-03T03:28:39Z

src/rotator_library/providers/iflow_auth_base.py

+            response = await client.get(
+                IFLOW_USER_INFO_ENDPOINT,
+                headers=headers,
+                params={"accessToken": access_token},


The _fetch_user_info method sends accessToken in both headers and query params. This could be a security concern if the token is logged in server access logs. Consider using only headers (preferred) or document why both are needed.

mirrobot-agent · 2026-03-03T03:28:39Z

src/rotator_library/transaction_logger.py

+        for filename in list(self._append_handles.keys()):
+            self._close_append_handle(filename)
+
+    def __del__(self) -> None:


The __del__ method calls close_append_files(), but relying on __del__ for cleanup is unreliable in Python (may not be called promptly or at all). Consider using context managers or explicit cleanup calls in addition to __del__.

Mirrowel · 2026-03-03T03:40:13Z

@mirrobot-agent also answer this comment: #142 (comment). From before, about other PRs.

What is here vs those other PRs, what is not, etc. Do not do any changes - just review and answer.

And do not just skim descriptions - read the diffs and verify as well vs latest dev branch.

mirrobot-agent · 2026-03-03T03:41:20Z

@Mirrowel, I've analyzed PR #142 against the latest dev branch and reviewed the three PRs you mentioned. Here's the breakdown:

PR Integration Status

✅ PR #136 (fix/iflow-cookie-auth-new-accounts) - INTEGRATED

Status: Changes ARE present in PR Harden iFlow proxy requests to match CLI behavior #142
Evidence: The iflow_auth_base.py changes in Harden iFlow proxy requests to match CLI behavior #142 include the null data detection and IFlowNoAPIKeyError handling from fix(iflow): handle null data for cookie auth on new accounts #136
What's included: Cookie-based authentication fixes for new iFlow accounts without API keys

❌ PR #130 (feat/iflow-add-new-models) - NOT INTEGRATED

Status: Changes are NOT present in PR Harden iFlow proxy requests to match CLI behavior #142
Missing models: minimax-m2.5, qwen3-32b, tstars2.0, iflow-rome-30ba3b
What Harden iFlow proxy requests to match CLI behavior #142 has: Only glm-5 from the 5 models requested in feat(iflow): add support for glm-5, minimax-m2.5, qwen3-32b, tstars2.0, iflow-rome-30ba3b #130
What you asked for: You specifically said "add minimax and anything else so this can be merged. Don't need the garbage models like qwen 32B or tstars"
Current state: PR Harden iFlow proxy requests to match CLI behavior #142 only includes glm-5 - minimax-m2.5 is missing

❌ PR #139 (fix/iflow-connection-error-handling) - PARTIALLY INTEGRATED

Status: Some changes overlap, but not fully integrated
What's in Harden iFlow proxy requests to match CLI behavior #142:
- Connection retry logic with exponential backoff (present)
- Silent context failure detection (present)
- httpx.RemoteProtocolError classification in error_handler.py (present)
What's different: Harden iFlow proxy requests to match CLI behavior #142 has its own implementation of these features, possibly rewritten

Summary

PR #142 currently contains:

✅ iFlow CLI-style anti-block behavior (core feature)
✅ OAuth credential handling improvements
✅ glm-5 model support
✅ Connection retry logic
✅ Cookie auth fixes for new accounts (fix(iflow): handle null data for cookie auth on new accounts #136)

Missing from PR #142:

❌ minimax-m2.5 model (from feat(iflow): add support for glm-5, minimax-m2.5, qwen3-32b, tstars2.0, iflow-rome-30ba3b #130) - you specifically requested this
❌ Other models from feat(iflow): add support for glm-5, minimax-m2.5, qwen3-32b, tstars2.0, iflow-rome-30ba3b #130 (qwen3-32b, tstars2.0, iflow-rome-30ba3b) - though you said these aren't needed

Recommendation: PR #142 needs minimax-m2.5 added to be ready for merge per your requirements.

This analysis was generated by an AI assistant.

Harden iFlow proxy requests to match CLI behavior

97e1449

Add signed-header fallback and base-url failover while fixing env OAuth credential loading/refresh so proxy calls are less likely to get blocked.

redzrush101 requested a review from Mirrowel as a code owner February 26, 2026 21:09

redzrush101 force-pushed the iflow-cli-spoof-port branch from 75bd2e0 to 407032e Compare February 27, 2026 12:18

yassin and others added 4 commits February 27, 2026 16:34

Reduce iFlow proxy stream logging overhead

b04c22e

Repository owner deleted a comment from mirrobot-agent bot Mar 3, 2026

mirrobot-agent bot reviewed Mar 3, 2026

View reviewed changes

Repository owner deleted a comment from mirrobot-agent bot Mar 3, 2026

Uh oh!

Conversation

redzrush101 commented Feb 26, 2026 • edited by ellipsis-dev bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Validation

Uh oh!

Mirrowel commented Feb 27, 2026

Uh oh!

redzrush101 commented Feb 27, 2026

Uh oh!

Mirrowel commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mirrobot-agent bot commented Mar 3, 2026

Uh oh!

mirrobot-agent bot left a comment

Choose a reason for hiding this comment

Overall Assessment

Architectural Feedback

Key Suggestions

Nitpicks and Minor Points

Questions for the Author

Uh oh!

mirrobot-agent bot Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

mirrobot-agent bot Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

mirrobot-agent bot Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

mirrobot-agent bot Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

mirrobot-agent bot Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

mirrobot-agent bot Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

Mirrowel commented Mar 3, 2026

Uh oh!

mirrobot-agent bot commented Mar 3, 2026

PR Integration Status

✅ PR #136 (fix/iflow-cookie-auth-new-accounts) - INTEGRATED

❌ PR #130 (feat/iflow-add-new-models) - NOT INTEGRATED

❌ PR #139 (fix/iflow-connection-error-handling) - PARTIALLY INTEGRATED

Summary

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

redzrush101 commented Feb 26, 2026 •

edited by ellipsis-dev bot

Loading

Mirrowel commented Mar 3, 2026 •

edited

Loading