[BUG]: "##[warning]Can't find loc string for key: Info_GotAndMaskAuth" started appearing after Universal Packages was updated to 0.243.1

[shiraze]

New issue checklist

• I searched for existing GitHub issues
• I read pipeline troubleshooting guide
• I checked how to collect logs

Task name

Universal packages

Task version

0.243.1

Issue Description

I get warning like the following after Universal Packages have been updated to v0.243.1:

##[warning]Can't find loc string for key: Info_GotAndMaskAuth
Downloading: https://04pvsblobproduks120.vsblob.vsassets.io/artifacttool/artifacttool-win10-x64-Release_0.2.350.zip?sv=2019-07-07&sr=b&sig=-REDACTED-&spr=https&se=2024-07-25T09%3A43%3A32Z&sp=r&P1=1721900312&P2=11&P3=2&P4=UVqeSQwPk1GYhKg7VZU6J35zISSLq2BpYsCBcbnFyus%3d
Caching tool: ArtifactTool 0.2.350 x64
##[warning]Can't find loc string for key: Info_GotAndMaskAuth

No changes were made to the pipeline, and these warning were not shown when using Universal Packages version 0.239.1

Environment type (Please select at least one enviroment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Operation system

windows-latest

Relevant log output

##[warning]Can't find loc string for key: Info_GotAndMaskAuth
Downloading: https://04pvsblobproduks120.vsblob.vsassets.io/artifacttool/artifacttool-win10-x64-Release_0.2.350.zip?sv=2019-07-07&sr=b&sig=-REDACTED-&spr=https&se=2024-07-25T09%3A43%3A32Z&sp=r&P1=1721900312&P2=11&P3=2&P4=UVqeSQwPk1GYhKg7VZU6J35zISSLq2BpYsCBcbnFyus%3d
Caching tool: ArtifactTool 0.2.350 x64
##[warning]Can't find loc string for key: Info_GotAndMaskAuth

Full task logs with system.debug enabled

 [REPLACE THIS WITH YOUR INFORMATION] 

Repro steps

trigger:
  - main

pool:
  vmImage: windows-latest

steps:
  - task: UniversalPackages@0
    displayName: Get build-tools
    inputs:
      command: 'download'
      downloadDirectory: '$(System.DefaultWorkingDirectory)\tools'
      feedsToUse: 'internal'
      vstsFeed: '9995297e-a424-4e13-b607-d51b434e1d4c'
      vstsFeedPackage: '65f008f1-d7f6-49c4-a8d5-02b3dc76b98c'
      vstsPackageVersion: '*'


  - task: UniversalPackages@0
    inputs:
      command: "publish"
      publishDirectory: '$(Build.StagingDirectory)\package'
      feedsToUsePublish: "internal"
      vstsFeedPublish: "4969b139-6618-4f41-9089-a75c46d25e61/cf675289-cd56-4a59-ade0-a71e193f9cc8"
      vstsFeedPackagePublish: 'something'
      versionOption: "patch"
      packagePublishDescription: 'some message'

[shiraze]

As a workaround, it's possible to pin to a specific version:
- task: UniversalPackages@0.239.1

[shiraze]

Note that the fix mentioned in #20130 (comment) doesn't resolve this issue; it only resolves the ENOENT error

[tintse-thxsky-MSFT]

@shiraze may you post the full log of the error with debug?

[tintse-thxsky-MSFT]

@shiraze I believe can you retry again and if the same error occurs, can you paste the logs (in text, preferably)? The first 20 lines of log is enough.

[RickMontalvoCubero]

We started to experience the same issue with task: UniversalPackages@0 recently. I looked at the report in #20130 and it seems that there is no fix for this at this time.

Do I have to provide a section of our logs as well?
Thanks in advance.

[shiraze]

Yes please!
I've not had a chance yet due to other commitments. Also, I'm only seeing a non-blocking warning.

The workaround is mentioned earlier, where you can pin to a specific version of the task

[RickMontalvoCubero]

Hi @shiraze,

We decided to wait on this and wait for the next update since it is just a warning at this time.

Thank you so much for your prompt response,
Rick

[shiraze]

@tintse-thxsky-MSFT I've attached a debug log of the failing task, and replaced references to our Org with
debug.txt

This is using Universal Packages 0.243.1, which is what UniversalPackages@0 currently picks up for me.

[shiraze]

Although the comment #20130 (comment) suggests that the fix to Universal Packages was made in 0.243.0+ I've only seen the issue when moving from 0.239.1 to 0.243.1

I don't think #20148 has fixed the issue

And it does seem that #20109 caused the issue, but pretty hard to find out how!

[shiraze]

Note that I'm no longer seeing this issue with Universal Packages 0.244.1, so will mark as fixed