Skip to content

refactor: remove all zelAppSpecifications legacy references#1717

Open
MorningLightMountain713 wants to merge 5 commits into
developmentfrom
fix/remove-zelappspecifications
Open

refactor: remove all zelAppSpecifications legacy references#1717
MorningLightMountain713 wants to merge 5 commits into
developmentfrom
fix/remove-zelappspecifications

Conversation

@MorningLightMountain713
Copy link
Copy Markdown
Contributor

@MorningLightMountain713 MorningLightMountain713 commented Apr 10, 2026

Summary

  • Remove all zelAppSpecifications fallbacks, duplicate queries, and dead indexes across 9 files
  • Add one-time startup migration that renames any zelAppSpecificationsappSpecifications in zelappsmessages and drops legacy indexes — safe for nodes that have been running since before Feb 2021 without a resync
  • Migration is idempotent (matches zero docs after first run) and runs once per boot via module-level flag
  • Verified on live node (chud): 57,253 records in zelappsmessages, 0 with zelAppSpecifications — all records use appSpecifications exclusively
  • Field name is not part of signed data, so no signature impact

Cleanup

Once all nodes on the network have been upgraded to this version, migrateZelAppSpecifications and the zelAppSpecsMigrationDone flag in explorerService.js can be removed.

Testing

  • Deploy to test node (cabbage)
  • Full sync from scratch completes successfully (57,468 messages synced, matches network)
  • Migration renames test zelAppSpecifications records and drops legacy indexes on boot
  • App owner queries return correct results (verified against 3 network nodes)
  • Global app specs and permanent messages counts match network

🤖 Generated with Claude Code

MorningLightMountain713 and others added 3 commits April 10, 2026 09:47
All records in zelappsmessages use appSpecifications exclusively —
verified on live node (57k records, 0 with zelAppSpecifications).
The field was normalized at ingestion time for years, so the fallbacks
and duplicate queries/indexes were dead code.

- Remove || zelAppSpecifications fallbacks across 7 files
- Remove duplicate $or query in appQueryService
- Remove duplicate zelAppSpecifications.name query blocks in
  advancedWorkflows and messageVerifier
- Remove 3 empty zelAppSpecifications.* indexes from explorerService
- Remove legacy field propagation in appHashSyncService

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Nodes running since before Feb 2021 may still have records in
zelappsmessages with the old zelAppSpecifications field name. This
migration renames them on startup and drops the legacy indexes.
Idempotent — matches zero docs once migrated. Safe to remove once
the fleet has been fully upgraded.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
… sync

The migration was inside the scannedBlockHeight === 0 block which only
runs on first sync. Existing nodes would never hit it. Move to run once
per process lifetime using a module-level flag, right after
isInInitiationOfBP is set.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@MorningLightMountain713 MorningLightMountain713 changed the title WIP: remove all zelAppSpecifications legacy references refactor: remove all zelAppSpecifications legacy references Apr 20, 2026
Copy link
Copy Markdown
Member

@Cabecinha84 Cabecinha84 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor observations (non-blocking)

  • Fresh install edge case: col.indexes() behavior on a never-created collection is driver/version dependent. In practice the collection is almost
    always pre-existing by this point in initiateBlockProcessor, but a defensive try/catch around migrateZelAppSpecifications (or an early
    listCollections check) would make fresh-node boots bulletproof.
  • Peer wire compatibility: the PR assumes every node on the network now emits appSpecifications. messageStore.storeAppTemporaryMessage will now
    reject any inbound message with only zelAppSpecifications. The author's justification ("since Feb 2021") is reasonable, but worth an explicit
    confirmation that no gossip path still carries the legacy field.
  • Cleanup note in PR body is good — flag and migration function can be deleted in a follow-up once the fleet is upgraded.

Recommendation

Ack. Optionally ask the author to wrap the migration call in a try/catch with a log line so a malformed fresh-sync DB can't stall block-processor
init.

Prevent migration failure from stalling block processor init on
fresh nodes or malformed DBs.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@MorningLightMountain713
Copy link
Copy Markdown
Contributor Author

Minor observations (non-blocking)

  • Fresh install edge case: col.indexes() behavior on a never-created collection is driver/version dependent. In practice the collection is almost
    always pre-existing by this point in initiateBlockProcessor, but a defensive try/catch around migrateZelAppSpecifications (or an early
    listCollections check) would make fresh-node boots bulletproof.
  • Peer wire compatibility: the PR assumes every node on the network now emits appSpecifications. messageStore.storeAppTemporaryMessage will now
    reject any inbound message with only zelAppSpecifications. The author's justification ("since Feb 2021") is reasonable, but worth an explicit
    confirmation that no gossip path still carries the legacy field.
  • Cleanup note in PR body is good — flag and migration function can be deleted in a follow-up once the fleet is upgraded.

Recommendation

Ack. Optionally ask the author to wrap the migration call in a try/catch with a log line so a malformed fresh-sync DB can't stall block-processor init.

Fixed. Wrapped in try / catch

Add setZelAppSpecsMigrationDone setter and mock updateMany/indexes on
collection fakes so the migration doesn't cause unexpected log.error
calls in existing tests.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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