Console ingestion: expose per-event outcomes for crashes submitted through the platform crash pipeline

Problem Statement

Console crashes reach Sentry through a platform-operated crash pipeline and vendor
middleware before Sentry ever sees them. When the count in the platform's own
dashboard does not match the count in Sentry, there is no way for the application
team to find out where the difference came from: whether the event was never
forwarded, was rejected at ingestion, was filtered, or was dropped for quota.

The consequence is not just a missing number. Once a team observes one mismatch they
stop trusting the crash pipeline generally, and every subsequent gap in the data is
attributed to tooling rather than investigated. That is an expensive failure mode to
recover from, and it is caused by a visibility gap rather than by any actual data
loss.

Application teams have no administrative view into the middleware layer and no way
to reason about it. Outcome data exists in aggregate but is not exposed for this
ingestion path in a way that answers "where did this specific crash go".

Solution Brainstorm

• Expose per-event outcomes and reasons for console-pipeline ingestion, queryable by
  the application team.
• Provide a processing view for this path showing what arrived at the middleware,
  what was forwarded, and what was rejected with a reason.
• Where Sentry genuinely cannot see upstream of its own middleware, state that
  boundary explicitly in the UI, so teams know which side of the line a gap falls on
  rather than assuming the worst.

Product Area

Ingestion

Requested by Saad Khan.

--

View Junior Session [Sentry]

The issue names no files, tests, or entry points. Start by clarifying the console crash ingestion boundary and the required per-event outcome data, then define how the processing view distinguishes forwarded, rejected, filtered, and quota-dropped events; done means application teams can query those outcomes and see where Sentry's visibility ends.