Skip to content

Set dandischema dependency to 0.12.0 and beyond#1744

Merged
yarikoptic merged 2 commits intomasterfrom
sync-schema-version-with-archive
Nov 24, 2025
Merged

Set dandischema dependency to 0.12.0 and beyond#1744
yarikoptic merged 2 commits intomasterfrom
sync-schema-version-with-archive

Conversation

@candleindark
Copy link
Member

@candleindark candleindark commented Nov 17, 2025

See individual commit message for details.

The CIs can only pass only if

@yarikoptic
Copy link
Member

0.12.0 schema was released

@yarikoptic
Copy link
Member

Note: as server does not really need anything "new" from dandi-cli, we ideally have server released/deployed first (people would be able to upload just fine) and then we ensure it is all green here and then merge/release

candleindark and others added 2 commits November 21, 2025 12:55
This allows syncing of `dandischema` version with
`dandi-archive` to resolve the `dandischema` versioning
issue stated in dandi/dandi-schema#344
as part of the effort to address
dandi/dandi-schema#299
…requirement

Co-authored-by: Yaroslav Halchenko <debian@onerussian.com>
@yarikoptic yarikoptic force-pushed the sync-schema-version-with-archive branch from 7386800 to f81c32e Compare November 21, 2025 20:55
@codecov
Copy link

codecov bot commented Nov 21, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.08%. Comparing base (8492260) to head (f81c32e).
⚠️ Report is 112 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1744   +/-   ##
=======================================
  Coverage   75.08%   75.08%           
=======================================
  Files          84       84           
  Lines       11874    11874           
=======================================
  Hits         8915     8915           
  Misses       2959     2959           
Flag Coverage Δ
unittests 75.08% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@yarikoptic yarikoptic merged commit 45c679a into master Nov 24, 2025
72 checks passed
@yarikoptic yarikoptic deleted the sync-schema-version-with-archive branch November 24, 2025 19:49
@github-actions
Copy link

🚀 PR was released in 0.74.0 🚀

yarikoptic added a commit that referenced this pull request Feb 13, 2026
The dandi-archive CLI integration tests started hanging for 6 hours
on November 24, 2025 (dandi/dandi-archive#1762).

Investigation of tinuous CI logs showed:

- Nov 21 (last success): test_nwb2asset_remote_asset XFAIL'd in 0.4s
- Nov 24 (first hang): same test hung for 6 hours until GitHub killed it
- ALL test runs on Nov 24-25 hung, across unrelated PRs

The code flow that hangs is:

  nwb2asset() → get_metadata() → _get_pynwb_metadata()
    → open_readable() → RemoteReadableAsset.open()
      → fsspec.open(url).open()
        → aiohttp HTTP read from minio in Docker
          → fsspec sync() blocks in threading.Event.wait()

The key environmental change between Nov 21 and Nov 24 was dandi-cli
PR #1744 updating dandischema from <0.12.0 to ~=0.12.0.  With
dandischema 0.11.x, the test hit a quick model validation mismatch
(completing as XFAIL in 0.4s before reaching the fsspec read).  With
dandischema 0.12.0 (vendor-configurable models, schema 0.7.0), that
mismatch no longer occurs, so the test now proceeds to the actual
fsspec HTTP read — which hangs.

The hang itself is a known interaction between h5py, fsspec, and GC:

- h5py holds a global lock while reading from Python file objects
- fsspec's sync() runs async aiohttp coroutines on a background thread
  and blocks the calling thread in threading.Event.wait()
- Without socket-level timeouts, aiohttp blocks forever on stalled
  connections (aio-libs/aiohttp#11740)
- GC running during this window can deadlock with h5py's lock
  (h5py/h5py#2019)

The fix: pass explicit ClientTimeout to aiohttp via fsspec's
client_kwargs so that stalled connections raise TimeoutError instead
of blocking indefinitely.

Additionally, the dandi-archive CI never had a pytest --timeout because
dandi-cli's tox.ini [pytest] addopts (--timeout=300) are not read when
pytest runs from the dandi-archive rootdir via `pytest --pyargs dandi`.

References:
- fsspec/filesystem_spec#1666
- h5py/h5py#2019
- aio-libs/aiohttp#11740
- #1762
- #1450

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

minor Increment the minor version when merged released

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants