### Summary On GitLab.com, the `get_artifact_file` MCP tool fails for every artifacts archive I tested up to ~10 KB. The error is: ``` Tool execution failed: new position is outside of file ``` Listing the archive works. Asking for a non-existent path returns the usual "not found … Files in the archive include: …" message. Only reading an entry fails. Large archives (15–16 MB) in the same pipelines read fine. The practical impact: security report artifacts (`gl-sast-report.json`, `gl-secret-detection-report.json`, `gl-container-scanning-report.json`) are typically only a few KB, so agents cannot read them. ### Steps to reproduce 1. Take a pipeline on GitLab.com with jobs that produce small `artifacts.zip` archives, for example the default SAST, Secret Detection or Container Scanning jobs from a security policy. 2. Call `get_pipeline` with `include: ["artifacts"]` to get job IDs and archive sizes. 3. Call `get_artifact_file` with `project_id`, `job_id` and an `artifact_path` that exists in the archive. ### What I observed Tested on 2026-09-28 in two private projects on GitLab.com, with several pipelines on feature branches, other long-lived branches and `main`: | Project | Job | `artifacts.zip` size | Entry | Result | |---|---|---|---|---| | B | custom lint job | 226 B | `gl-code-quality-report.json` | ❌ `new position is outside of file` | | A | custom job | 396 B | small text file | ❌ same | | B | `secret-detection-0` | 726 B | `gl-secret-detection-report.json` | ❌ same | | A | custom job | 749 B | small text file | ❌ same | | A | `secret-detection-0` | 1,447 B | `gl-secret-detection-report.json` | ❌ same | | B | `container-scanning-0` | 1,683 B | `gl-container-scanning-report.json` | ❌ same | | A | `gitlab-advanced-sast-2` | 2,143 B | `gl-sast-report.json` | ❌ same | | A | `gemnasium-dependency-scanning-1` | 2,470 B | CycloneDX SBOM (`gl-sbom-*.cdx.json`) | ❌ same | | B | `semgrep-sast-2` | 9,945 B | `gl-sast-report.json` (99,993 B uncompressed) | ❌ same | | B | custom build job | 15,464,784 B | compiled binary | ✅ entry opened (rejected as binary, which is expected) | | A | custom build job | 16,154,479 B | compiled binary | ✅ entry opened (rejected as binary, which is expected) | - **Parameters make no difference:** Setting `byte_offset: 0` with a small `byte_limit` (1 or 100) gives the same error. - **Listing works:** A lookup of a non-existent path lists the archive's files correctly for every archive above. - **Archive size matters, not entry size:** The 9,945 B archive fails even though its entry is ~100 KB uncompressed. - **Threshold not narrowed down:** I had no archives between ~10 KB and ~15 MB, so I could not narrow down the exact threshold. ### What is the current *bug* behavior? Reading any entry from a small archive fails with a generic `Tool execution failed: new position is outside of file`. ### What is the expected *correct* behavior? The entry is returned, as it is for larger archives. If reading really fails, the tool should at least return the `archive_unreadable_error` introduced in !255762 ("Could not read the artifacts archive of job N. Download it from … instead."). ### Analysis (partly hypothesis) - **Where the message comes from (confirmed):** It is the `RuntimeError` raised by `Gitlab::HttpIO#seek` (`lib/gitlab/http_io.rb`). Stack traces in #30521 and #371481 show this. - **Likely regression:** !255762 (merged 2026-09-24) switched `get_artifact_file` to `Zip::File.open_buffer` on `Gitlab::HttpIO` via `Mcp::Tools::RangedZipIo`. - **Why the fallback message does not appear:** `read_from_archive` rescues `Gitlab::HttpIO::FailedToGetChunkError`, `Zip::Error` and `Zlib::Error`, but not the `RuntimeError` from `HttpIO#seek`. That is why the generic "Tool execution failed" message appears instead of `archive_unreadable_error`. - **Hypothesis, not verified in the source:** When rubyzip scans for the end-of-central-directory record, it seeks a fixed distance back from the end of the file, roughly 64 KB. For a plain `File`, seeking before offset 0 raises `Errno::EINVAL`, and rubyzip handles that. `HttpIO#seek` raises a `RuntimeError` instead, which rubyzip does not expect. This would affect every archive smaller than that distance. The observations above (all archives ≤ ~10 KB fail, archives ≥ 15 MB work) are consistent with this. - **Test gap:** The MR adds a spec with a *large* archive in object storage. Local-storage specs get a plain `File` and do not go through `HttpIO`. A *small* archive in object storage does not seem to be covered. ### Possible fixes - In `RangedZipIo#seek`, clamp negative target positions to 0, or translate the out-of-range error into `Errno::EINVAL` so that rubyzip falls back as it does for a `File`. - Add the `RuntimeError` case, or a dedicated error class in `HttpIO`, to the rescue in `read_from_archive`. - Add a spec for a small archive (for example < 1 KB) in object storage. ### Related - !255762, #629157, !254894 ### Side note (separate issue?) Report-type artifacts that are uploaded separately and not included in `artifacts.zip` cannot be read with `get_artifact_file` at all, even though `get_pipeline`/`get_job` with `include: ["artifacts"]` lists them. Example from both projects: `gl-dependency-scanning-report.json` (`file_type: dependency_scanning`). The tool answers "not found in the artifacts archive" and lists only the CycloneDX SBOM.