Skip to content

Wr/fix heap oom large custom labels @W-21251439@#1795

Draft
WillieRuemmele wants to merge 4 commits into
mainfrom
wr/fixHeapOomLargeCustomLabels
Draft

Wr/fix heap oom large custom labels @W-21251439@#1795
WillieRuemmele wants to merge 4 commits into
mainfrom
wr/fixHeapOomLargeCustomLabels

Conversation

@WillieRuemmele

@WillieRuemmele WillieRuemmele commented Jun 26, 2026

Copy link
Copy Markdown
Member

What does this PR do?

What issues does this PR fix or reference?

#, @W-21251439@

Functionality Before

<insert gif and/or summary>

Functionality After

<insert gif and/or summary>

Metadata Registry: Successful Deploy and Retrieve (required if applicable)

Deploy output:

<paste CLI output and/or screenshot>

Retrieve output:

<paste CLI output and/or screenshot>


Summary of Changes

Problem

When multiple package directories contain the same CustomLabels file (common in multi-package projects), the recomposition finalizer (source→metadata conversion for deploy) was accumulating duplicate children. With large label files across 2-3 packages, this caused the merged output to double or triple in size, leading to heap OOM crashes.

Fix: recompositionFinalizer.ts

Added deduplicateChildren() — when the same label (keyed by type.name#fullName) appears from multiple packages, only the first occurrence is kept. This is safe because:

  • The merged CustomLabels.labels is an ephemeral artifact for deploy (zipped and sent to the org, never written to disk).
  • Retrieve uses nonDecompositionFinalizer, which writes labels back to their respective package directories — users never see git diffs.
  • Identical labels in multiple packages are the same logical metadata member; deploying it twice was already a no-op on the org side.

Fix: nonDecompositionFinalizer.ts

Refactored initMergeMap to parse each parent XML file once and extract all children directly, rather than re-parsing the parent for every individual child component. This eliminates redundant XML parsing that scaled quadratically with label count.

Snapshot diff (~16k lines)

The customLabels-multiple test snapshot went from 32,918 lines to 16,471 — almost exactly halved. The test data has labels across 2 packages (second-app and third-app) with largely identical content, so the old behavior was duplicating nearly every entry. The ~92 "additions" in the diff are ordering artifacts from the dedup changing sort positions, not new labels.

New test: customLabels-merged

A focused snapshot test with small synthetic data (3 packages, 8 unique labels, 2 shared across packages) to verify the dedup behavior explicitly without relying on the large real-world test data.

…r-child

Previously initMergeMap called child.parseXml() for each child, which
re-parsed the entire parent XML file (e.g. 31K lines) for every one of
3,945 children. Now parses each parent once and extracts children
directly from the parsed result.
Verifies correctness of multi-package merge with deduplication:
- Labels unique to each package are preserved
- Shared labels (same fullName) are deduplicated
- First-encountered definition wins on conflicting content
@WillieRuemmele WillieRuemmele changed the title Wr/fix heap oom large custom labels Wr/fix heap oom large custom labels @W-21251439@ Jun 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants