Add backend observability for contract event schema drifts

[grantfox-oss]

Backend parsers can silently ignore contract events when schema shapes drift, causing gaps in ingestion and stale data for analytics and reconciliation.

Affected areas: app/backend/src/ingestion/soroban-event.parser.ts, app/backend/src/ingestion/types/contract-event.types.ts, app/backend/src/monitoring/*, app/backend/src/sentry/*, app/backend/src/logging/*.

Implementation scope:

• Add metrics and alerts for unknown event names, field mismatches, and parser rejections.
• Capture contract ID, event name, schema version, and raw payload for rejected events in safe diagnostics.
• Add a drift detector that compares runtime events to expected schema metadata.
• Expose a developer-facing status endpoint for parser health.

Acceptance criteria:

• Schema mismatches are visible in monitoring instead of only debug logs.
• Unknown events are classified and counted separately from parse errors.
• Alerts fire when ingestion rejects more than a threshold of events in a time window.

[Chigybillionz]

Heloo maintainer

I would like to work on this issue.

Experience:
I have experience with NestJS, TypeScript, event-driven architectures, observability, monitoring, logging systems, Sentry integration, and backend ingestion pipelines. I have worked on schema validation, event processing reliability, alerting systems, and production monitoring for distributed applications.

Implementation:
I will enhance the Soroban event ingestion pipeline by introducing structured metrics and monitoring for unknown events, schema mismatches, and parser failures. I will implement safe diagnostics that capture contract ID, event name, schema version, and raw payload metadata for rejected events, build a drift-detection mechanism against expected event schemas, and expose a developer-facing parser health endpoint. I will also integrate alerting thresholds to proactively detect ingestion degradation and schema drift.

Delivery:
I can complete the implementation, testing, monitoring integration, and documentation within 8–12 hours, ensuring parser failures become observable, actionable, and protected against silent data loss.

GitHub:
https://github.com/chigybillionz

[Achievers-sketch]

Experienced with backend observability, monitoring, logging, and TypeScript. I can implement schema-drift detection, alerts, metrics, and tests.

[Glam26]

I'd like to take this issue.

I've worked on event-ingestion and observability pipelines where schema drift between on-chain events and backend parsers caused silent data loss. In similar systems, I've implemented parser-health metrics, structured diagnostics, Sentry instrumentation, and alerting to surface ingestion failures before they impact analytics or reconciliation.

My approach will be to add explicit classification for unknown events, schema mismatches, and parser rejections; capture safe diagnostic context (contract ID, event name, schema version, and payload metadata); implement runtime schema-drift detection against the expected event definitions; and expose parser-health visibility through a dedicated status endpoint.

I'll also add monitoring and alert thresholds so elevated rejection rates are immediately visible to operators rather than remaining buried in logs. The goal is to make ingestion failures measurable, actionable, and easy to investigate while avoiding sensitive-data exposure.

[okeolaolatun23-glitch]

Experienced in backend development, APIs, and OOP, with a strong interest in building scalable and maintainable software systems.

[noevidence1017]

Hello Maintainer. I am a fullstack dev and i've checked through this issue. I would love to resolve this issue as soon. Please assign

[Y33t-dev]

Hello Maintainer , I would love to resolve this issue as I am familiar with it. Please assign

[BigManly4]

Hello maintainer, I would love to resolve this issue within few hours. I am a Full-stack dev with contributions to Oss projects. Please assign

[Marodrumz]

Hi BlockDash-Studios team,

I would like to work on this issue because silent contract event parser drift is a serious backend reliability risk. If Soroban event shapes change and the backend quietly ignores or rejects them, analytics, reconciliation, and downstream data can become stale without operators noticing quickly.

My plan is to study the current ingestion flow first, especially app/backend/src/ingestion/soroban-event.parser.ts, app/backend/src/ingestion/types/contract-event.types.ts, and the existing monitoring, Sentry, and logging modules. Then I will add observability around schema drift without changing unrelated ingestion behavior.

I will focus on:

• Adding metrics for unknown event names
• Adding metrics for field mismatches
• Adding metrics for parser rejections
• Separating unknown events from actual parse errors
• Capturing safe diagnostics for rejected events
• Including contract ID, event name, schema version, and raw payload where safe
• Adding a drift detector that compares runtime events against expected schema metadata
• Exposing a developer-facing parser health/status endpoint
• Adding threshold-based alerts for rejection spikes over a time window
• Ensuring sensitive data is not leaked in logs, Sentry, or diagnostics
• Updating tests for unknown events, schema mismatches, and rejection thresholds
• Running the backend test/lint/typecheck commands before submitting

I have experience with backend observability, TypeScript/NestJS-style systems, event ingestion pipelines, structured logging, monitoring, Sentry-style diagnostics, and production reliability work. I understand that this issue is not just about logging errors; the goal is to make schema drift measurable, classifiable, alertable, and safe for operators to investigate.

If assigned, I will submit a focused PR that adds parser drift metrics, safe rejection diagnostics, classified monitoring, alert threshold behavior, a parser health endpoint, and automated coverage for the touched backend paths.

[Menjay7]

Hi! I came across this issue and would love to work on it. I have experience with similar tasks and I'm confident I can investigate, implement a clean solution, and thoroughly test it before submitting a PR. If the issue is still open, I would appreciate it if you could assign it to me. Thank you!

[Promise278]

i have experience with backend design and archecture please i would love to work on these project please