mj sync push never applies a deleteRecord marker on a nested relatedEntities record
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- sql, typescript
Research direction
Start in packages/MetadataSync/src/services/PushService.ts at the deletion pre-scan near line 2442, then inspect the recursive hasAnyDeletions helper near line 2657. Reproduce with mj sync push --dir metadata --verbose using a metadata file whose only deletion marker is nested under relatedEntities. Done means the pre-scan recognizes the nested marker, the deletion audit emits the appropriate DELETE into the SQL log without deleting dependents first, and a regression test covers this case.
Written by the indexing model from the issue text.
Description
Summary
PushService's deletion pre-scan checks only each file's top-level records for deleteRecord.delete === true. When the only delete markers in a run are on nested relatedEntities records, it logs "No deletion operations found" and skips the deletion phase, so the rows stay in the database and in the SQL log a release Metadata_Sync migration is built from. The class already has a recursive helper, hasAnyDeletions, that the pre-scan does not use.
What happened
Follow-up from bizapps-common PR #198 (known limitation stated in the PR), never filed: https://github.com/MemberJunction/bizapps-common/pull/198
#198 marked two nested EntityActionParam rows deleteRecord and measured against a copy of a dev database: the push summary said Deleted 0, both rows remained, and the logged SQL had no DELETE. It worked around this with a hand-written migration plus a test (metadata-nested-deletes.test.ts) that requires such a migration "until MJ applies nested deletes". The pre-scan on MJ next is unchanged.
Expected: a nested deleteRecord marker deletes the row, as a top-level one does.
Actual: the push skips the deletion phase and reports nothing deleted.
Steps to reproduce
- In a metadata file, add
"deleteRecord": { "delete": true }to one record under a parent'srelatedEntities, with no top-level delete anywhere in the run. mj sync push --dir metadata --verbose: logs "No deletion operations found - skipping deletion audit."; the row is still in the database.
Confidence
Inferred from code, not observed (the PR measured it on a database copy)
Environment
MJ 6.1.0-edge.6 (observed in #198); code unchanged on MJ next f6faded · bizapps-common @ next c8fdaf5 (consumer)
Severity proposed
degraded
Target line
next + backport to the current release line
Duplicate search
Searched issues "nested deleteRecord", "mj sync push nested delete", "deleteRecord relatedEntities", "No deletion operations found" and PRs "nested deleteRecord push" across MemberJunction — found MJ#4935 (open, related: delete order within a push; not the pre-scan) and MJ#4836 (closed, unrelated).
Blocking?
Not blocked — apps can delete nested rows with a hand-written migration.
Suspected cause (optional)
packages/MetadataSync/src/services/PushService.ts:2442 (MJ next): records.some((r: RecordData) => r.deleteRecord?.delete === true) looks only at top-level records; when nothing matches, :2454-2459 returns null and the deletion audit never runs. hasAnyDeletions at :2657-2675 recurses into relatedEntities but is not used by this pre-scan.
Proposed fix (optional) — tested? yes / no
Proposed: call hasAnyDeletions(records) in the pre-scan, then confirm the deletion audit orders nested deletes after their dependents and emits DELETE into the SQL log.
Tested: no
- Dominant language
- TSQL
- Stars
- 32
- Forks
- 7
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 714
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MemberJunction/MJ
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
MemberJunction/MJ#6024 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
MemberJunction/MJ#6018 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
MemberJunction/MJ#6012 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
MemberJunction/MJ#5952 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
MemberJunction/MJ#5930 ·
Maintainers usually reply within 1 day
All issues in MemberJunction/MJ
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Eval bug: minimax-m3: build_moe_ffn() drops the per-expert NVFP4 scale → garbled output (M3.1 Flash)Openbug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
openminion/openminion#376 ·
Maintainers usually reply within 1 day
-
integration: apple_tv
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
home-assistant/core#188282 · 1 comment ·
Maintainers usually reply within 1 day
-
A "since" range is worded as a career: "the past two seasons" says "regular season career (2025 on)"OpenP4: low
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
jeffknupp/association#538 ·