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.

1. 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.)
2. Open the Decap project in the browser.
3. 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
…

Applicable Versions:

• Decap CMS version: 3.0.0
• Git provider: Azure
• OS: MacOS
• Browser version: Chrome 120

CMS configuration

backend:
  name: azure
  repo: {org}/{project}/{repo}
  branch: main
  tenant_id: {…}
  app_id: {…}

publish_mode: editorial_workflow

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.