Skip to content

fix(10.x.x): keep SynchronizedDataLoader when the registry has an instrumentation, and synchronize loadMany. - #2216

Merged
samuelAndalon merged 1 commit into
ExpediaGroup:10.x.xfrom
eocantu:fix/synchronized-dataloader-transform-loadmany
Oct 1, 2026
Merged

samuelAndalon merged 1 commit into
ExpediaGroup:10.x.xfrom
eocantu:fix/synchronized-dataloader-transform-loadmany

Conversation

@eocantu

@eocantu eocantu commented Sep 23, 2026

Copy link
Copy Markdown
Contributor

📝 Description

SynchronizedDataLoader (#2202) has two gaps that let concurrent loads on a cached, non-batching loader call the downstream more than once:

  • DataLoaderRegistry rebuilds each loader with transform(...) to add its name and instrumentation. DelegatingDataLoader.transform returns the plain delegate, so the wrapper is lost whenever a DataLoaderInstrumentation is passed to generate(...), which is always the case with SYNC_EXHAUSTION. transform now re-wraps the result.
  • loadMany bypasses the wrapper and calls the delegate's loadImpl directly. That includes getValuesFromDataLoader. The three loadMany overloads are now synchronized like load.

🔗 Related Issues

Follow-up to #2202, which addressed the loss of load synchronization

@samuelAndalon
samuelAndalon merged commit 5ebef48 into ExpediaGroup:10.x.x Oct 1, 2026
8 checks passed
samuelAndalon pushed a commit that referenced this pull request Oct 1, 2026
…tion, and synchronize loadMany (#2220)

### 📝 Description

Cherry-picked from 5ebef48
(#2216)

### 🔗 Related Issues
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants