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.