Dependency dashboard not create work items for Azure DevOps

[Sander0542]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

Other (please specify)

Which version of Renovate are you using?

43.210.2

Please tell us more about your question or problem

After PR #42758 was merged I upgrades Renovate to gain support for the Dependency Dashboard on Azure DevOps. After Renovate ran it didn't create any Work Items, then when I looked at the logs I found out why. The Azure DevOps WorkItems API is returning 400 status codes on the System.State field (See logs below).

Related to #42758

Logs

Logs

 WARN: Error ensuring issue (repository=REDACTED)
       "err": {
         "statusCode": 400,
         "result": {
           "$id": "1",
           "customProperties": {
             "FieldReferenceName": null,
             "FieldStatusFlags": "none",
             "ErrorMessage": "The field 'State' contains the value 'New' that is not in the list of supported values",
             "FieldStatusCode": 0,
             "RuleValidationErrors": [
               {
                 "fieldReferenceName": "System.State",
                 "fieldStatusFlags": "required, hasValues, limitedToValues, invalidListValue",
                 "errorMessage": "The field 'State' contains the value 'New' that is not in the list of supported values",
                 "fieldStatusCode": 4194317,
                 "ruleValidationErrors": null
               }
             ]
           },
           "innerException": null,
           "message": "The field 'State' contains the value 'New' that is not in the list of supported values",
           "typeName": "Microsoft.TeamFoundation.WorkItemTracking.Server.RuleValidationException, Microsoft.TeamFoundation.WorkItemTracking.Server",
           "typeKey": "RuleValidationException",
           "errorCode": 0,
           "eventId": 3200
         },
         "responseHeaders": {
           "cache-control": "no-cache",
           "pragma": "no-cache",
           "content-length": "827",
           "content-type": "application/json; charset=utf-8",
           "expires": "-1",
           "p3p": "CP=\"CAO DSP COR ADMa DEV CONo TELo CUR PSA PSD TAI IVDo OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR LOC CNT\"",
           "x-tfs-processid": "REDACTED",
           "strict-transport-security": "max-age=31536000; includeSubDomains",
           "activityid": "REDACTED",
           "x-tfs-session": "REDACTED",
           "x-vss-e2eid": "REDACTED",
           "x-vss-senderdeploymentid": "REDACTED",
           "x-vss-userdata": "REDACTED",
           "x-frame-options": "SAMEORIGIN",
           "x-ratelimit-cost": "0.05922",
           "request-context": "REDACTED",
           "access-control-expose-headers": "Request-Context",
           "x-content-type-options": "nosniff",
           "x-cache": "CONFIG_NOCACHE",
           "x-msedge-ref": "REDACTED",
           "date": "Wed, 03 Jun 2026 22:01:47 GMT",
           "connection": "close"
         },
         "message": "The field 'State' contains the value 'New' that is not in the list of supported values"
       }
       Error: The field 'State' contains the value 'New' that is not in the list of supported values
           at RestClient.<anonymous> (/opt/hostedtoolcache/node/24.16.0/x64/lib/node_modules/renovate/node_modules/typed-rest-client/RestClient.js:204:31)
           at Generator.next (<anonymous>)
           at fulfilled (/opt/hostedtoolcache/node/24.16.0/x64/lib/node_modules/renovate/node_modules/typed-rest-client/RestClient.js:7:58)
           at processTicksAndRejections (node:internal/process/task_queues:104:5)

[bkje14]

I got the same issue.
Look like that the default Agile and Basic (did not look at other) azure processes do not support the "New" state for issue work items.
can provide logs if needed.

[sebdanielsson]

If neither Agile nor Basic processes are compatible with the current implementation, I'm curious what process this feature was tested against?

[Sander0542]

If you go into the Azure DevOps Organization settings, then to process. You can see 4 default processes.

Process	Type	Open State	Close State
Basic	Issue	To Do	Done
Agile	Issue	Active	Closed
Scrum	No issue type	-	-
CMMI	Issue	Proposed / Active	Closed

We should fetch which process the project is using and then set the correct state on closing. For opening we can leave it to the default value. I suggest merging PR #43786 to at least fix the opening part first and in the meantime work on a fix for closing the Work Item.

[jan-mrm]

yea I guess 'Issues' seem to exist in Agile I just was not aware of them and only used 'Bug'. They seem to not come up in the Backlog view and stuff but they exist and are findable. So probably all good on that front.
I like the idea to merge that PR for now to get it working.
Also I like the idea of making it configurable so that custom setups can work with it too. Else the process being used could be discovered / fetched to use the correct defaults (or maybe they can also be fetched somehow), but maybe thats another step then.

[rQcAnE4pk15VDHVa]

Processes can be created and changed. I prefer renovate being able to adjust to that elementary config rather than adjusting a config/process to the tool.

[sanderjochems-capgemini]

Processes can be created and changed. I prefer renovate being able to adjust to that elementary config rather than adjusting a config/process to the tool.

That is exactly what @illay1994 created in PR #44132

[Sander0542]

I created PR #43786 which could resolve the issue

[github-actions[bot]]

Hi there,

This is intended as a polite, automated request that users avoid @ mentioning repository maintainers like @viceice. Doing so causes annoying mobile notifications and makes it harder to maintain this repository.

We know it might be common elsewhere but we participate in hundreds of discussions a week and would need to turn off GitHub mobile notifications if we were mentioned in every one.

As a general rule, we will read and respond to all discussions in this repository, so there is no need to mention us.

Thanks, the Renovate team

[illay1994]

I created draft PR #44132.

[sanderjochems-capgemini]

What should we discuss for this PR to be opened again?

[sanderjochems-capgemini]

Looking at the PR this provides a good way to make configurations specific to the Azure DevOps platform, because there is no API to call to get the values we need. This PR would solve the issue and make it fully configurable

[dnperfors]

I've got a similar issue (Unable to evaluate path /multilineFieldsFormat/System.Description.), however:

1. I use the preset :disableDependencyDashboard, so I would expect no creation of issues
2. Issues are disabled on our Azure Devops Server (on-premise installation)

--- edit ---
Never mind, turns out that the :disableDependencyDashboard was not set on the configuration used for the repository itself. Clearly I need to see if I can simplify our config 😆

[emanuelbesliu]

Proposal: autodetect Azure DevOps work item states instead of hardcoding New/Closed

Following up on this — the root cause is that lib/modules/platform/azure/issue.ts hardcodes System.State: 'New' on create/reopen and 'Closed' on close. Azure DevOps defines states per work-item-type per process, so any process without those exact names rejects the request:

The field 'State' contains the value 'New' that is not in the list of supported values

This blocks the Dependency Dashboard entirely (e.g. Basic uses To Do/Done; custom inherited processes vary).

I'd like to propose a zero-config autodetect approach (rather than the config-option route in #44132):

• Read the Issue type's states via getWorkItemTypeStates and group them by state category (Proposed/InProgress = open; Completed/Resolved/Removed = closed) — categories are stable across all processes even when the display names differ.
• Omit System.State on create so Azure DevOps applies the type's default initial state (valid on every process).
• Classify existing issues open/closed by category instead of the literal Closed.
• Fall back to the current New/Closed names if the states can't be read (e.g. older ADO Server).

This fixes create, reopen, and close with no new config. I have a branch ready with 100% test coverage and a readme note, and I'm happy to open a PR if this direction is acceptable.

[emanuelbesliu]

I've opened a PR implementing this: #44412