>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3632382. --> Reported by: [pawelgorski87](https://www.drupal.org/user/3139083) >>> <h3>Problem/Motivation</h3> <p>Batch exports retain completed ViewExecutable instances across iterations within the same PHP process. DataExport::buildBatch() and DataExport::doProcessBatch() call preExecute() without a matching postExecute(). Core preExecute() stores the previous current View in old_view and sets $GLOBALS['_current_view']; without postExecute(), successive iterations can retain a chain of Views and result entities.</p> <p>This is separate from <a href="https://www.drupal.org/project/views_data_export/issues/3586574">#3586574</a>: the tested installation already includes disconnectWorksheets(), and memory growth was also observed with CSV.</p> <h4>Environment</h4> <ul> <li>Drupal 11.4.7, PHP 8.3.35</li> <li>Views data export 8.x-1.10; XLS Serialization 2.1.0</li> <li>Patch 48 from #3173296 was also present; reproduction without that additional patch still needs confirmation.</li> </ul> <h4>Steps to reproduce</h4> <ol> <li>Create several thousand records with entity-backed exported fields.</li> <li>Configure a batch export with deterministic sorting on a unique identifier and a batch size of 10 or 50.</li> <li>Run multiple iterations within one PHP process (a synchronous batch or Drush batch worker).</li> <li>Monitor memory and compare the current View reference before and after the export.</li> <li>Repeat with CSV to distinguish this from XLSX workbook retention.</li> </ol> <p>Observed before the candidate fix: native exports exhausted the available 512 MiB container budget at approximately 1,600 records for XLSX and 2,350 for CSV. Thresholds depend on fields and execution context. Expected: each explicit preExecute() is paired with postExecute(), including exception paths, so the previous View is restored and completed iterations can be released.</p> <h3>Proposed resolution</h3> <p>Pair preExecute()/postExecute() using try/finally in the count and iteration paths, then destroy the completed per-iteration View. The candidate patch additionally clears entity.memory_cache and invokes PHP garbage collection. Those additional controls should be reviewed independently; measurements below test the combined patch and do not isolate each cleanup step.</p> <h4>Local validation</h4> <ul> <li>2,788 records, XLSX, batch size 10: both Drush and a bootstrapped Drupal HTTP request context without Drush completed.</li> <li>All cells matched the baseline export: 2,789 rows including the header.</li> <li>Fresh web container with a hard 512 MiB limit and no swap: about 455 MiB peak via Drush and 376 MiB via Drupal, with no OOM events. These are aggregate container measurements, not PHP-only peaks.</li> <li>The previous current View was restored and batch state cleared.</li> <li>Integration coverage crosses a batch boundary with 11 fixtures and checks complete row count, each fixture exactly once, and downloadable XLSX.</li> </ul> <p>A container with warmed PHP-FPM workers still exceeded the same aggregate budget. This change does not guarantee a total 512 MiB budget under concurrent web workloads.</p> <h3>Remaining tasks</h3> <ul> <li>Add module-level regression tests for restoring the previous current View in success and exception paths.</li> <li>Confirm against the current development branch without additional patches.</li> <li>Review entity-cache clearing and explicit garbage collection.</li> <li>Verify progressive browser exports as well as synchronous/Drush execution.</li> </ul> <h3>User interface changes</h3> <p>None.</p> <h3>API changes</h3> <p>No public API changes intended.</p> <h3>Data model changes</h3> <p>None.</p>