Truncation Occurs On Small Responses #719
Description
Describe the bug
Opening a fresh Copilot CLI instance and sending a small prompt to GPT-5.1 causes immediate truncation. This may be a UI bug.
Here are two attempts at reproducing this. Both are fresh terminals, but the second log is an attempted continuation of the first prompt using a fresh terminal. You may notice that I'm nowhere close to the context window limits.
Truncation #1:
Welcome to GitHub Copilot CLI
Version 0.0.363 · Commit 66416ad
Copilot can write, test and debug code right from your terminal. Describe a task to get started or enter ? for help. Copilot uses AI, check for mistakes.
● Logged in as user: AlexanderJohnston
● Connected to GitHub MCP Server
> Currently if the name of the first column (FILENAME / FILEPATH) changes then the @DelFormatPipeline\Manifest\ExcelManifestReader.cs and its associated pipeline fails to locate the PDF files. What is our current
strategy for finding that column or how is it parsed?
✔ Read DelFormatPipeline\Manifest\ExcelManifestReader.cs:1-end
└ 5 lines read
● In ExcelManifestReader, the column is not dynamically detected by header name; it is effectively hard‑coded by position/config. The reader builds a DataTable from the Excel sheet, then uses configured column
indexes (e.g., from ExcelManifestReaderColumnRules / similar mapping) to pull values, so if the first column changes name or order, the logic still assumes that first column is the file identifier
(FILENAME/FILEPATH). Because it does not search headers by text (e.g., “FILENAME” or “FILEPATH”) and instead relies on that fixed index, changing the header breaks the downstream PDF lookup.
> List out the hard-coded headers for me.
● Viewing the ExcelManifestReader source to extract and list any hard-coded header names.
✔ Read DelFormatPipeline\Manifest\ExcelManifestReader.cs:1-end
└ 5 lines read
✘ Model call failed: {"message":"Invalid 'input[7].content': array too long. Expected an array with maximum length 0, but got an array with length 1 instead.","code":"invalid_request_body"} (Request ID:
0433:D6D5:275515B:2C858F6:6931BE54)
● Operation cancelled by user
Total usage est: 2 Premium requests
Total duration (API): 14s
Total duration (wall): 3m 28.76s
Total code changes: 0 lines added, 0 lines removed
Usage by model:
gpt-5.1-2025-11-13 25.1k input, 396 output, 22.8k cache read (Est. 2 Premium requests)
Shutting down...
Truncation #2:
Welcome to GitHub Copilot CLI
Version 0.0.366 · Commit 0c18d21
Copilot can write, test and debug code right from your terminal. Describe a task to get started or enter ? for help. Copilot uses AI, check for mistakes.
● Logged in as user: AlexanderJohnston
● Connected to GitHub MCP Server
> Continue where the failure occurred: Version 0.0.363 · Commit 66416ad
Copilot can write, test and debug code right from your terminal. Describe a task to get started or enter ? for help. Copilot uses AI, check for mistakes.
● Logged in as user: AlexanderJohnston
● Connected to GitHub MCP Server
> Currently if the name of the first column (FILENAME / FILEPATH) changes then the @DelFormatPipeline\Manifest\ExcelManifestReader.cs and its associated pipeline fails to locate the PDF files. What is our
current
strategy for finding that column or how is it parsed?
✔ Read DelFormatPipeline\Manifest\ExcelManifestReader.cs:1-end
5 lines read
● In ExcelManifestReader, the column is not dynamically detected by header name; it is effectively hard‑coded by position/config. The reader builds a DataTable from the Excel sheet, then uses configured column
indexes (e.g., from ExcelManifestReaderColumnRules / similar mapping) to pull values, so if the first column changes name or order, the logic still assumes that first column is the file identifier
(FILENAME/FILEPATH). Because it does not search headers by text (e.g., “FILENAME” or “FILEPATH”) and instead relies on that fixed index, changing the header breaks the downstream PDF lookup.
> List out the hard-coded headers for me.
● Viewing the ExcelManifestReader source to extract and list any hard-coded header names.
✔ Read DelFormatPipeline\Manifest\ExcelManifestReader.cs:1-end
5 lines read
✘ Model call failed: {"message":"Invalid 'input[7].content': array too long. Expected an array with maximum length 0, but got an array with length 1 instead.","code":"invalid_request_body"} (Request ID:
0433:D6D5:275515B:2C858F6:6931BE54)
● Operation cancelled by user
~\Desktop\Utility\CLIENT\DelFormatTool[⎇ main*]
✔ Read DelFormatPipeline\Manifest\ExcelManifestReader.cs:1-end
└ 219 lines read
● From this file, the only hard-coded header names are "FILENAME" and "FILEPATH".
They are used in TryGetValue(headerMap, values, "FILENAME", ...) (required) and TryGetValue(headerMap, values, "FILEPATH", ...) (optional), plus a comparison if (string.Equals(headerName, "FILENAME", ...)) when
building the metadata dictionary.
> What and how are those two headers used for/
● FILENAME is treated as the required document identifier: each non-empty row must have a FILENAME cell, otherwise the row is either skipped (if fully empty) or causes an InvalidDataException, and that value
becomes ManifestDocument.FileName (trimmed).
FILEPATH is optional and, if present, is treated as the declared directory/folder path for the file, becoming ManifestDocument.DeclaredDirectory (trimmed or null if blank).
All other headers (anything not equal to "FILENAME", case-insensitive) are used as metadata keys, with their cell values stored in the ManifestDocument.Metadata dictionary.
~\Desktop\Utility\CLIENT\DelFormatTool[⎇ main*] gpt-5.1 (1x) ● Truncated
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
> Enter @ to mention files or / for commands
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Ctrl+c Exit · Ctrl+r Expand recent
Affected version
0.0.366
Commit: 0c18d21
Steps to reproduce the behavior
Open a new terminal pointed at GPT-5.1 and ask it a basic question on a small repository.
Context window report does not match with what the UI is telling me (that Truncation occurred when it shouldn't).
Expected behavior
No Truncation should occur unless context window is hit.
Additional context
No response