Helix work item details API doesn't correctly handle subdirectories in the Files key

[akoeplinger]

Example: https://helix.dot.net/api/jobs/5b165e06-0424-4dd9-a216-b4b959a9c2c0/workitems/GC-scenarios1/?api-version=2019-06-17

{
  "Queued": "2025-08-21T10:03:49.473+00:00",
  "Started": "2025-08-21T10:28:59.548+00:00",
  "Finished": "2025-08-21T10:31:13.897+00:00",
  "Delay": "00:25:10.0750000",
  "Duration": "00:02:14.3490000",
  "Id": "0934fb79-fa2f-4c9d-aca1-2ee135604529",
  "MachineName": "a003E65",
  "ExitCode": 0,
  "ConsoleOutputUri": "https://helix.dot.net/api/jobs/5b165e06-0424-4dd9-a216-b4b959a9c2c0/workitems/GC-scenarios1/files/console.33f5aacc.log?api-version=2019-06-17",
  "Errors": [],
  "Warnings": [],
  "Logs": [
    {
      "Module": "run_client.py",
      "Uri": "https://helix.dot.net/api/jobs/5b165e06-0424-4dd9-a216-b4b959a9c2c0/workitems/GC-scenarios1/files/247e66f9-96ca-4ea9-bd4c-b07f62d12f07.log?api-version=2019-06-17"
    }
  ],
  "Files": [
    {
      "FileName": "xharness-output/testResults.xml",
      "Uri": "https://helix.dot.net/api/jobs/5b165e06-0424-4dd9-a216-b4b959a9c2c0/workitems/GC-scenarios1/files/testResults.xml?api-version=2019-06-17"
    },
    {
      "FileName": "xharness-output/wasm-console.log",
      "Uri": "https://helix.dot.net/api/jobs/5b165e06-0424-4dd9-a216-b4b959a9c2c0/workitems/GC-scenarios1/files/wasm-console.log?api-version=2019-06-17"
    },
    {
      "FileName": "console.33f5aacc.log",
      "Uri": "https://helix.dot.net/api/jobs/5b165e06-0424-4dd9-a216-b4b959a9c2c0/workitems/GC-scenarios1/files/console.33f5aacc.log?api-version=2019-06-17"
    }
  ],
  "Job": "5b165e06-0424-4dd9-a216-b4b959a9c2c0",
  "Name": "GC-scenarios1",
  "State": "Passed"
}

For example the wasm-console.log file was uploaded from the xharness-output subdirectory in HELIX_WORKITEM_UPLOAD_ROOT.
If I look at the Files table in Kusto it was uploaded to a reasonable URI: https://helixr1107v0xdcypoyl9e7f.blob.core.windows.net/dotnet-runtime-refs-pull-118730-merge-5b165e0604244dd9a2/GC-scenarios1/1/xharness-output/wasm-console.log?helixlogtype=result

But the /files URL in the response doesn't take that subdirectory into account so if you try to load it it won't work.

This is because of this handling here: https://dev.azure.com/dnceng/internal/_git/dotnet-helix-service?path=/src/ServiceFabric/Helix/HelixAPI/Api/v2016_04_07/Controllers/WorkItemController.cs&version=GBmain&line=131&lineEnd=174&lineStartColumn=1&lineEndColumn=10&lineStyle=plain&_a=contents

We just take the last segment of the URI:

  string fileName = uri.Segments.LastOrDefault();

I think we could fix this by using the FileName we already have here: https://dev.azure.com/dnceng/internal/_git/dotnet-helix-service?path=/src/ServiceFabric/Helix/HelixAPI/Api/v2016_08_25/Controllers/WorkItemController.cs&version=GBmain&_a=contents&line=133&lineStyle=plain&lineEnd=134&lineStartColumn=1&lineEndColumn=1 instead of extracting it from the URI.

Note that if we do that we also have some file names that need to be escaped, for example:

  {
    "Name": "xharness-output\\logs\\DebugLevelTests_BuildWithDefaultLevel_Debug_False_l4eibqsr_ygv_鿀蜒枛遫䡫煉\\WasmBasicTestApp-build.binlog",
    "Link": "https://helixr1107v0xdcypoyl9e7f.blob.core.windows.net/dotnet-runtime-refs-pull-118916-merge-88c0682dd2484152a8/Workloads-ST-Wasm.Build.Tests.DebugLevelTests/1/xharness-output/logs/DebugLevelTests_BuildWithDefaultLevel_Debug_False_l4eibqsr_ygv_%E9%BF%80%E8%9C%92%E6%9E%9B%E9%81%AB%E4%A1%AB%E7%85%89/WasmBasicTestApp-build.binlog?helixlogtype=result"
  },

Alternatively, if we could just always return the blob storage URL directly that would work too.

Release Note Category

• Feature changes/additions
• Bug fixes
• Internal Infrastructure Improvements

Release Note Description

[premun]

@missymessa is this still the right place to open issues on or should we turn this into an AzDO task?

[missymessa]

@premun this is fine until we get everything migrated to AzDO. Thanks for checking!

[missymessa]

Needs to be moved.

[akoeplinger]

friendly ping, this is still causing issues for our team

[lewing]

I ran into this while trying to download binlogs from Helix CI results for dotnet/runtime#124125. The WASM build tests produce artifacts with CJK characters in directory names (e.g. 鿀蜒枛遫䡫煉), making 53 out of 62 files in a work item inaccessible via the Details API.

There are actually two separate bugs:

1. Subdirectory flattening (as you described): uri.Segments.LastOrDefault() loses the directory path, so multiple files with the same base name (e.g. BlazorBasicTestApp-publish.binlog in different test subdirectories) all get the same permalink URI.

2. Unicode rejection: Even when the FileName is used to construct the permalink (as in the WIP fix), the GetFile endpoint's regex ([^A-Za-z0-9-._~!$&'()*+,;=:@%/]) rejects the decoded unicode characters. ASP.NET's {\*file} catch-all decodes percent-encoded paths before passing them to the action, so %E9%BF%80 becomes 鿀 and the regex blocks it.

Workaround: The ListFiles endpoint (GET .../workitems/{id}/files) returns direct blob storage URIs that bypass both issues entirely. I've updated our CI analysis script to use this instead of the Details endpoint's Files URIs.

Fix PR: I've also opened AzDO PR #57709 with a fix that:

• Passes FileName through to WorkItemFilePermalink for Files entries (preserves subdirectory paths)
• Replaces the ASCII-only regex with a simple \.\. path traversal check (allows unicode while maintaining security — the file parameter is still matched against known FileNames from the database)

[missymessa]

Migrated to https://dnceng.visualstudio.com/internal/_workitems/edit/9799.