xarray.backends.locks.CombinedLock.locked() always returns true

[carlini]

What happened?

The CombinedLock.locked() method incorrectly accesses lock.locked as a property instead of calling lock.locked() as a method, causing it to always return True when any locks are present, regardless of whether they are actually acquired.

xarray/xarray/backends/locks.py

Lines 235 to 236 in 3572f4e

	def locked(self):
	return any(lock.locked for lock in self.locks)

What did you expect to happen?

No response

Minimal Complete Verifiable Example

# /// script
# requires-python = ">=3.11"
# dependencies = [
#   "xarray[complete]@git+https://github.com/pydata/xarray.git@main",
# ]
# ///
#
# This script automatically imports the development branch of xarray to check for issues.
# Please delete this header if you have _not_ tested this script with `uv run`!

import xarray as xr
xr.show_versions()

import threading
from xarray.backends.locks import CombinedLock

# Create two threading locks
lock1 = threading.Lock()
lock2 = threading.Lock()

# Create a CombinedLock with these locks
combined = CombinedLock([lock1, lock2])

print(f"combined.locked() returns: {combined.locked()}")

Steps to reproduce

No response

MVCE confirmation

• Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• Complete example — the example is self-contained, including all data and the text of any traceback.
• Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• New issue — a search of GitHub Issues suggests this is not a duplicate.
• Recent environment — the issue occurs with the latest version of xarray and its dependencies.

Relevant log output

Anything else we need to know?

I discovered this bug as part of a project where we are use LLMs to search for bugs in popular open source repositories. Before filing this bug, we paid for three expert human reviewers to validate this bug, and I also manually validated the bug on my own machines. I am confident that the bug is real, I wrote and filed this report manually, and take responsibility for this bug report.

Environment

INSTALLED VERSIONS

commit: None
python: 3.13.2 | packaged by Anaconda, Inc. | (main, Feb 6 2025, 18:56:02) [GCC 11.2.0]
python-bits: 64
OS: Linux
OS-release: 6.14.0-1017-gcp
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: C.UTF-8
LOCALE: ('C', 'UTF-8')
libhdf5: None
libnetcdf: None

xarray: 2025.9.0
pandas: 2.3.2
numpy: 2.3.3
scipy: None
netCDF4: None
pydap: None
h5netcdf: None
h5py: None
zarr: None
cftime: None
nc_time_axis: None
iris: None
bottleneck: None
dask: None
distributed: None
matplotlib: None
cartopy: None
seaborn: None
numbagg: None
fsspec: None
cupy: None
pint: None
sparse: None
flox: None
numpy_groupies: None
setuptools: None
pip: 24.3.1
conda: None
pytest: 8.4.2
mypy: None
IPython: None
sphinx: None

[dcherian]

nice find. I wish there was a typecheker/linter rule to catch this kind of thing