[bugfix] track delta embeddings by owner-qualified FQN

[tiankongdeguiji]

Summary

• track touched embedding IDs by canonical, owner-qualified table FQN
• keep same-named tables under different sharded EC/EBC owners independent
• use FQN keys throughout shard metadata, static weights, dynamic modules, lookup validation, and parquet output
• omit retained FQN buckets that have no unread IDs, allowing later quiet dump intervals to complete normally
• use TorchRec 1.7's concrete owner, grouped-lookup, embedding-config, sharding-metadata, ShardedTensor, and DTensor interfaces
• fail fast on unsupported lookup and weight implementations
• bump the TorchEasyRec version to 1.3.6

Root cause

The previous tracking path built global mappings keyed by raw table name. When separate sharded modules owned tables with the same name, the later mapping could overwrite the earlier one, causing feature mappings, touched IDs, and embedding lookups to resolve to the wrong owner.

Additionally, DeltaStoreTrec.delete(up_to_idx=...) retains FQN buckets with empty lookup lists. A later interval with no new IDs for a previously seen table could therefore reach torch.cat([]) inside TorchRec's get_unique() implementation instead of reaching the dumper's empty-output path.

Implementation

The delta dump now has an ID-only tracker built directly on TorchRec's abstract ModelDeltaTracker. Each lookup callback uses its owning sharded module to resolve a module-local feature-to-FQN mapping, so IDs remain attached to the exact EC/EBC owner that produced them.

DeltaEmbeddingDumper carries that FQN directly through metadata and storage collection and into table_fqn output. Dynamicemb extracts only the final table-name component where its table index API requires it; no fqn_to_table mapping is introduced.

The tracker builds unique rows only from unread lookups in each FQN bucket and omits buckets with no unread IDs. Consumer cursors, delete-on-read, compaction, and empty-shard behavior remain unchanged.

The implementation intentionally uses the supported TorchRec 1.7 interfaces instead of accepting arbitrary lookalike objects through defensive reflection. The sole remaining getattr selects the active protobuf oneof field. The parquet schema, configuration, and dump scheduling are unchanged.

Test Plan

Run in the tzrec130 environment:

• PYTHONPATH=. python -m tzrec.utils.delta_embedding_dump_test — 43 tests passed, including two consecutive intervals where the second has no unread IDs, duplicate EC/EBC owners, row-wise sharding, static and DTensor weights, pause guards, dynamicemb, and multi-process DMP regressions
• pre-commit run -a — passed
• git diff --check — passed
• python scripts/pyre_check.py — blocked by existing environment/repository constraints: the committed .pyre_configuration is invalid JSON, and the Pyre backend requires newer GLIBC/GLIBCXX symbols than the host provides

[github-actions]

DeltaStoreTrec.delete(up_to_idx=...) retains FQN buckets with empty lookup lists. After one dump, if a previously seen table has no unread IDs in a later interval, this reaches torch.cat([]) inside get_unique() and aborts before the dumper's empty-output path. Please prune/omit empty unread buckets and add a two-interval regression.

[github-actions]

Static review complete. I left one inline comment: after a prior dump, DeltaStoreTrec retains empty FQN buckets, so a previously seen table with no unread IDs in a later interval can trigger torch.cat([]) and abort dumping. No other noteworthy findings. Tests and builds were not run, as requested.