-
[OPIK-7309] [BE] Wire span deletions into the deletion-events bridge (trace-delete cascade) + ArchUnit guard (#7511)
frostbyte_neo 发布于
2026-07-20 10:07:58 +00:00 - [OPIK-7309] [BE] Wire span deletions into the deletion-events bridge (trace-delete cascade) + ArchUnit guard
Capture span-row deletions in the deletion_events_local bridge so they survive
the Slice 3 spans table copy (R-19). Spans have no standalone delete, so capture
wires into the only span-deletion path — the trace-delete cascade
(SpanService.deleteByTraceIds -> spanDAO.deleteByIds) — recording source_table=spans.
Gated by spanDeletionEventsCaptureEnabled (default off); best-effort and deferred,
run only after a successful delete, so it can never disrupt a delete. Retention
paths excluded. Spans counterpart of OPIK-6890 (#7376) + OPIK-6891 (#7390).Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- [OPIK-7309] [BE] review: cover spanless-trace cascade (no delete/capture)
Add a unit test asserting a trace with no spans short-circuits before the
lightweight delete and capture, completing cleanly with no deletion events.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- [OPIK-7309] [BE] review: post SpansDeleted before capture, matching TraceService order
Address review: capture was chained inside the flatMap before the SpansDeleted
event fired in the outer doOnSuccess, diverging from TraceService.delete which
posts the event first then .then(captureDeletions). Move the event post ahead of
the best-effort capture so the span path mirrors the trace path exactly; behavior
is unchanged (capture is deferred, gated, and swallows errors, so the event always
fires regardless of capture outcome).Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- [OPIK-7309] [BE] review: CASCADE deletion reason + consolidate deletion-event tests
Address review (Andrés):
- Span deletions are always cascaded from trace/other-entity deletes, never
direct user requests: add DeletionReason.CASCADE and use it in
SpanService.captureDeletions. deletion_reason is LowCardinality(String), so no
migration is needed. - Revert the capture/event ordering to post SpansDeleted in the outer
doOnSuccess (keeping the reviewed approach; the order is irrelevant since the
event is async and unrelated to this bridge). - Consolidate the deletion-event integration coverage: rename
TraceDeletionEventTest -> DeletionEventTest and extend its trace-cascade cases
to also assert the cascaded span rows (source_table=spans, reason=cascade);
drop the duplicate SpanDeletionEventTest. Span capture runs on the async
AsyncEventBus cascade, so only the span assertion polls with Awaitility while
trace capture stays synchronous.
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
Co-authored-by: Claude Opus 4.8 (1M context) noreply@anthropic.com
下载附件