JobMonitor: Resubmitted work items are submitted with missing info

[mmitche]

When resubmitting work items, certain metadata may not be populated:

• Repository
• Branch
• SourcePrefix
• TeamProject

var creationRequest = new JobCreationRequest(details.Type, newJobListUri, details.QueueId)
            {
                Source = details.Source,
                Creator = details.Creator,
                Properties = ConvertPropertiesToImmutableDictionary(details.Properties)
                    .SetItem(HelixJobInfo.PreviousHelixJobNamePropertyName, originalJobName),
            };

Compare the submitted job creation request details as compared to a fresh submission by the Helix SDK. These should be the same.

[mmitche]

Investigation: precise field-level diff (fresh submission vs. resubmission)

I compared the resubmitted job against its original, using a concrete example from build 1447093:

• Original (fresh SDK submission): b65dd800-2c33-4f6c-b615-efcaddcdac69
• Resubmitted by JobMonitor: 00282884-53f6-4e3e-bb36-1fac41de8609 (PreviousHelixJobName points back to the original)

The resubmission request is built in HelixService.ResubmitWorkItemsAsync (src/Microsoft.DotNet.Helix/JobMonitor/Services/HelixService.cs), which only copies Source, Creator, and Properties:

var creationRequest = new JobCreationRequest(details.Type, newJobListUri, details.QueueId)
{
    Source = details.Source,
    Creator = details.Creator,
    Properties = ConvertPropertiesToImmutableDictionary(details.Properties)
        .SetItem(HelixJobInfo.PreviousHelixJobNamePropertyName, originalJobName),
};

Compare to the fresh path in JobDefinition.SendAsync (src/Microsoft.DotNet.Helix/JobSender/JobDefinition.cs), which additionally sets ResultContainerPrefix, DockerTag, and QueueAlias:

var creationRequest = new JobCreationRequest(Type, jobListUri.ToString(), queueId)
{
    Properties = _properties.ToImmutableDictionary(),
    Creator = Creator,
    ResultContainerPrefix = ResultContainerPrefix,
    DockerTag = dockerTag,
    QueueAlias = queueAlias,
};

What is actually missing

1. ResultContainerPrefix — CONFIRMED missing (highest confidence)

Result/console blobs land in a different storage container:

• Original work item console log container: dotnet-arcade-refs-pull-16956-merge-b65dd8002c334f6cb6 (i.e. <repo>-<branch>-<jobid>)
• Resubmitted work item console log container: results-0028288453f64e3ebb (generic results-<jobid>, no repo/branch prefix)

The fresh path computes ResultContainerPrefix = "<BUILD_REPOSITORY_NAME>-<BUILD_SOURCEBRANCH>-" (JobDefinition.cs lines ~204-218). The resubmission never sets it, so the prefix is lost. Fix: recompute/copy ResultContainerPrefix (it can be derived from the original job's Source/properties).

2. DockerTag and QueueAlias — almost certainly missing (high confidence)

This job ran inside a Docker container. The operatingSystem property is:
(AlmaLinux.9.Amd64.Open)Ubuntu.2204.Amd64.Open@mcr.microsoft.com/dotnet-buildtools/prereqs:almalinux-9-helix-amd64
which decomposes to: QueueAlias=AlmaLinux.9.Amd64.Open, QueueId=Ubuntu.2204.Amd64.Open, DockerTag=mcr.microsoft.com/dotnet-buildtools/prereqs:almalinux-9-helix-amd64.

Job.DetailsAsync returns only the resolved QueueId (ubuntu.2204.amd64.open) and does not expose DockerTag/QueueAlias. Because the resubmission copies details.QueueId and sets neither DockerTag nor QueueAlias, the resubmitted work item likely runs directly on Ubuntu 22.04 instead of inside the almalinux-9 container — a real execution-environment regression. The Docker image info still survives in the operatingSystem property string, so a fix can re-parse it from there (same parsing logic as JobDefinition.ParseQueueId).

What is NOT the problem (correcting the original report)

• Build is NOT missing. It is empty ("Build":"") in both the original and the resubmitted job. The arcade Helix SDK does not populate Build (the typed JobCreationRequest model has no Build property at all), so this is expected, not a regression.
• Repository / Branch / SourcePrefix / TeamProject are intentionally omitted here. The fresh path only sets these when Source is empty (InitializeSourceParameters), and the Helix API returns 400 if both Source and any of those are set (see JobDefinition.cs lines ~230-239). Since the resubmission correctly copies the server-computed Source (pr/public/dotnet/arcade/refs/pull/16956/merge), these four are mutually exclusive with it and should remain unset. They are a red herring for this scenario.

Actionable fix checklist

• Set ResultContainerPrefix on the resubmission request (derive <repo>-<branch>- from the original job's Source/properties).
• Set DockerTag and QueueAlias, parsed from the original job's operatingSystem property (reuse ParseQueueId logic).
• Add a regression test asserting a resubmitted JobCreationRequest matches a fresh one for ResultContainerPrefix, DockerTag, and QueueAlias (extend the existing tests in JobMonitorRunnerTests.cs / HelixService tests).
• Leave Source/Properties copying as-is; do not add Repository/Branch/SourcePrefix/TeamProject (would 400 alongside Source).

[mmitche]

Investigation complete. Outcome:

• Build is empty in both fresh and resubmitted jobs — not a regression.
• Repository/Branch/SourcePrefix/TeamProject are intentionally omitted when Source is set (API 400s otherwise) — not a problem.
• ResultContainerPrefix difference is a non-issue.

The one concrete, confirmed regression — resubmitted work items losing DockerTag/QueueAlias (wrong execution environment) — has been split into its own actionable issue: #16961. Closing this in favor of that.