XX-net/XX-Net · warning

RangeFetch get left, begin:%d end:%d

Error message

RangeFetch get left, begin:%d end:%d

What it means

After the inner read loop, the worker still hasn't covered the requested range (begin < end+1): reads ended early and retries within the loop did not complete the span. The worker logs the uncovered begin/end and loops for another retry round.

Source

Thrown at code/default/gae_proxy/local/gae_handler.py:1013

                    break

                data_len = len(data)
                data_readed += data_len
                if data_len > expect_len:
                    xlog.warn("RangeFetch expect:%d, get:%d",
                              expect_len, data_len)
                    data = data[:expect_len]
                    data_len = expect_len

                self.put_data(begin, data)

                expect_len -= data_len
                begin += data_len

            if begin >= end + 1:
                break

            xlog.warn("RangeFetch get left, begin:%d end:%d", begin, end)

    def close(self):
        self.keep_running = False
        with self.lock:
            self.waiter.notify()

View on GitHub (pinned to cfa5bc17b6)

Solutions

1. Ensure stable front IPs and healthy appid quota
2. Retry the download; RangeFetch re-requests the missing span
3. If repeated to the retry cap, see error 76 handling

When it happens

Trigger: The read loop for a range ends (empty read or short data) with begin < end+1, so the uncovered portion is logged and the outer while retries the remaining span.

Common situations: Same as 76/77: unstable IPs, server dropping range connections, quota errors causing partial range reads.

Related errors

• download size:%d, need size:%d, download fail.
• front retry %s%s
• response length incorrect, head len:%s, content len:%d retry
• report fail.

AI-assisted analysis of XX-net/XX-Net@cfa5bc17b6 (2026-08-27). Data as JSON: /api/errors/6311284e6a743f76. Report an issue: GitHub.