Describe the bug
The Workflow screen fails to load. It gets stuck in the 'Loading Editorial Workflow Entries' state after showing the error message Failed to load entry: TypeError: Cannot read properties of undefined (reading 'some').
To Reproduce
The behavior appears when collaborating through Azure DevOps on a branch with both Decap and non-Decap PRs.
Given a Decap project
using Azure backend
configured to use main branch
with Editorial Workflow enabled.
In the Azure DevOps UI (not through Decap), create a PR against main. (In other words, create a PR against same branch that Decap is also configured for.)
Open the Decap project in the browser.
Navigate to the Workflow screen (e.g. /admin/#/workflow).
After that, you can prevent the buggy behavior by going to the same PR in the Azure DevOps UI, and adding at least one label (content doesn't matter).
Expected behavior
The Workflow screen should load and function as intended, regardless of what other PRs are in place
Screenshots
Trace
API.js:467 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'some')
at API.js:467:24
at Array.filter (<anonymous>)
at t.default.getPullRequests (API.js:466:35)
at async t.default.listUnpublishedBranches (API.js:474:5)
at async t.unpublishedEntries (implementation.js:62:5)
at async t.default.unpublishedEntries (implementation.js:238:5)
at async K.unpublishedEntries (backend.js:755:11)
(anonymous) @ API.js:467
getPullRequests @ API.js:466
Promise.catch (async)
(anonymous) @ editorialWorkflow.js:276
(anonymous) @ index.js:16
n.<computed> @ bindActionCreators.js:9
componentDidMount @ Workflow.js:55
…
Additional context
The root cause can rightfully be considered a bug in the Azure DevOps REST API. Their documentation indicates that a labels field will always be present when listing pull requests. However, that is not the case in practice. In a support thread, a Microsoft rep indicates that it might actually be intended behavior (pointing to a specific API endpoint for PR labels).
Decap's Azure backend API implementation assumes that the returned pr objects will have a labels property.
We could change the getPullRequests implementation such that the pullRequests.filter also works if pr.labels is undefined.
I believe it wouldn't hurt to add that improvement, especially since any Azure DevOps API would take time (if it indeed would happen).
Happy to prep a PR if maintainers confirm it makes sense.
Describe the bug The Workflow screen fails to load. It gets stuck in the 'Loading Editorial Workflow Entries' state after showing the error message
Failed to load entry: TypeError: Cannot read properties of undefined (reading 'some')
.To Reproduce The behavior appears when collaborating through Azure DevOps on a branch with both Decap and non-Decap PRs.
Given a Decap project
main
branchmain
. (In other words, create a PR against same branch that Decap is also configured for.)/admin/#/workflow
).After that, you can prevent the buggy behavior by going to the same PR in the Azure DevOps UI, and adding at least one label (content doesn't matter).
Expected behavior The Workflow screen should load and function as intended, regardless of what other PRs are in place
Screenshots![decap-workflow-typeerror](https://github.com/decaporg/decap-cms/assets/80429/9062abb6-e79b-4f0d-855e-27a16f3e7155)
Trace
Applicable Versions:
CMS configuration
Additional context The root cause can rightfully be considered a bug in the Azure DevOps REST API. Their documentation indicates that a
labels
field will always be present when listing pull requests. However, that is not the case in practice. In a support thread, a Microsoft rep indicates that it might actually be intended behavior (pointing to a specific API endpoint for PR labels).Decap's Azure backend API implementation assumes that the returned pr objects will have a
labels
property.We could change the
getPullRequests
implementation such that thepullRequests.filter
also works ifpr.labels
is undefined.I believe it wouldn't hurt to add that improvement, especially since any Azure DevOps API would take time (if it indeed would happen).
Happy to prep a PR if maintainers confirm it makes sense.