feat(events): preserve event topic compatibility across upgrades (#1391)

[Chris-P-web]

Problem

Event topics were emitted via inline symbol_short!() literals at every emit site, with no central registry. EventSchemaRegistry only covered 4 of ~100 events. There was no mechanism to:

• emit under both old + new topic during rolling upgrade windows
• preserve per-topic nonces across upgrades (risking replay-protection reset)
• allow on-chain consumers to discover topic renames

Changes

New: src/event_topic_compat.rs

• EventTopicRegistry: compile-time table of all ~100 event topics with schema_version, symbol, and human-readable name. Single source of truth for every emit site.
• EventCompatBridge: dual-publish helper that emits under both the old and new topic symbol during compatibility windows. Safe to call when old == new (emits once, no duplication).
• TopicAlias + DataKey::EventTopicAlias: persisted alias records written by the upgrade hook so on-chain consumers can discover topic renames.
• EventNonceGuard: snapshot/restore helpers for per-topic nonces — prevents monotonically-increasing guarantee from breaking across upgrades.
• CompatEmit: emit helper that resolves topic + schema_version from registry.

Modified: src/events.rs

• EventSchemaRegistry::get_schema now delegates to EventTopicRegistry for ALL events (was hardcoded to 4). Backward-compatible: existing callers continue to work with the same API.
• New EventSchemaRegistry::get_all_schemas() returns schemas for every topic.
• New EventSchemaRegistry::topic_count() for off-chain health checks.

Modified: src/storage.rs

• Added DataKey::EventTopicAlias(Symbol) variant for persisted alias records.

Modified: src/upgrade_manager.rs

• preserve_event_nonces / restore_event_nonces: snapshot/restore nonce hook.
• register_topic_aliases: registers all TOPIC_ALIASES in persistent storage.
• prepare_event_compat / finalize_event_compat: combined pre/post-upgrade hooks.

New: src/event_topic_compat_tests.rs

• 30+ focused tests covering:
  • Registry completeness (every topic is retrievable by name and symbol)
  • Schema version integrity (all versions >= 1, deterministic)
  • EventSchemaRegistry delegation for all topics + legacy names
  • DataKey::EventTopicAlias storage round-trip
  • Alias persistence, idempotency, get_alias/register_alias
  • Nonce preserve/restore round-trip, no-rollback invariant, empty-state no-op
  • Compat bridge single-emit (same topic) and dual-emit (different topics)
  • UpgradeManager prepare_event_compat/finalize_event_compat integration
  • Regression: snapshot survives failed restore, retry works correctly

Invariants preserved

• EventTopicRegistry::get never panics on unknown input
• EventCompatBridge::publish_with_compat is idempotent
• Nonce restore never rolls back (only restores if snapshot > current)
• All existing callers remain compatible (get_schema API unchanged)

Closes #1391

Pull Request Description

📋 Basic Information

Type of Change

Please select the type of change this PR introduces:

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• 🧪 Test addition/update
• 🔧 Refactoring (no functional changes)
• ⚡ Performance improvement
• 🔒 Security fix
• 🎨 UI/UX improvement
• 🚀 Deployment/Infrastructure change

Related Issues

Closes #(issue number)
Fixes #(issue number)
Related to #(issue number)

Priority Level

• 🔴 Critical (blocking other development)
• 🟡 High (significant impact)
• 🟢 Medium (moderate impact)
• 🔵 Low (minor improvement)

---

📝 Detailed Description

What does this PR do?

Why is this change needed?

How was this tested?

Alternative Solutions Considered

---

🏗️ Smart Contract Specific

Contract Changes

Please check all that apply:

• Core contract logic modified
• Oracle integration changes (Pyth/Reflector)
• New functions added
• Existing functions modified
• Storage structure changes
• Events added/modified
• Error handling improved
• Gas optimization
• Access control changes
• Admin functions modified
• Fee structure changes

Oracle Integration

• Pyth oracle integration affected
• Reflector oracle integration affected
• Oracle configuration changes
• Price feed handling modified
• Oracle fallback mechanisms
• Price validation logic

Market Resolution Logic

• Hybrid resolution algorithm changed
• Dispute mechanism modified
• Fee structure updated
• Voting mechanism changes
• Community weight calculation
• Oracle weight calculation

Security Considerations

• Access control reviewed
• Reentrancy protection
• Input validation
• Overflow/underflow protection
• Oracle manipulation protection

---

🧪 Testing

Test Coverage

• Unit tests added/updated
• Integration tests added/updated
• All tests passing locally
• Manual testing completed
• Oracle integration tested
• Edge cases covered
• Error conditions tested
• Gas usage optimized
• Cross-contract interactions tested

Test Results

# Paste test output here
cargo test
# Expected output: X tests passed, Y tests failed

Manual Testing Steps

---

📚 Documentation

Documentation Updates

• README updated
• Code comments added/updated
• API documentation updated
• Examples updated
• Deployment instructions updated
• Contributing guidelines updated
• Architecture documentation updated

Breaking Changes

Breaking Changes:

Migration Guide:

---

🔍 Code Quality

Code Review Checklist

• Code follows Rust/Soroban best practices
• Self-review completed
• No unnecessary code duplication
• Error handling is appropriate
• Logging/monitoring added where needed
• Security considerations addressed
• Performance implications considered
• Code is readable and well-commented
• Variable names are descriptive
• Functions are focused and small

Performance Impact

• Gas Usage:
• Storage Impact:
• Computational Complexity:

Security Review

• No obvious security vulnerabilities
• Access controls properly implemented
• Input validation in place
• Oracle data properly validated
• No sensitive data exposed

---

🚀 Deployment & Integration

Deployment Notes

• Network: Testnet/Mainnet
• Contract Address:
• Migration Required: Yes/No
• Special Instructions:

Integration Points

• Frontend integration considered
• API changes documented
• Backward compatibility maintained
• Third-party integrations updated

---

📊 Impact Assessment

User Impact

• End Users:
• Developers:
• Admins:

Business Impact

• Revenue:
• User Experience:
• Technical Debt:

---

✅ Final Checklist

Pre-Submission

• Code follows Rust/Soroban best practices
• All CI checks passing
• No breaking changes (or breaking changes are documented)
• Ready for review
• PR description is complete and accurate
• All required sections filled out
• Test results included
• Documentation updated

Review Readiness

• Self-review completed
• Code is clean and well-formatted
• Commit messages are clear and descriptive
• Branch is up to date with main
• No merge conflicts

---

📸 Screenshots (if applicable)

🔗 Additional Resources

• Design Document:
• Technical Spec:
• Related Discussion:
• External Documentation:

---

💬 Notes for Reviewers

Please pay special attention to:

Questions for reviewers:

---

Thank you for your contribution to Predictify! 🚀

Closes #1391

[drips-wave]

@Chris-P-web Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits