-
[OPIK-7306] [BE] feat: add id_at column migration to spans; keep retention on trace_id (#7471)
frostbyte_neo 发布于
2026-07-16 09:51:05 +00:00 - [OPIK-7306] [BE] feat: add id_at predicate to SpanDAO retention paths
Mirror of the traces work (OPIK_6894) on the 14 TB spans table so the
retention sweep engages partition pruning post-cutover, load-bearing for
OPIK_5295 reclaim.- Migration 000103 adds id_at (DateTime('UTC') MATERIALIZED
UUIDv7ToDateTime(toUUID(id))) to spans, metadata-only, mirror of 000091. - Add a toMonday(id_at) week-bounds predicate to deleteForRetention,
countForRetention, and deleteForRetentionBounded. A span's id_at is >= its
trace's time, so the bounds never narrow the trace-id-ranged deletion set;
the upper bound advances one week so spans sharing the cutoff week stay in
scope. No-op pre-cutover, prunes once spans is PARTITION BY toMonday(id_at)
(spans counterpart of OPIK_6900).
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- [OPIK-7306] [BE] test: stress addWeeks upper bound on all three span retention paths
Parameterize the bounded-delete and count boundary tests Tuesday-Sunday with
the deletable span in the cutoff's own ISO week, so the
toMonday(id_at) < addWeeks(toMonday(cutoff), 1) upper bound is exercised on
every retention path, not just the unbounded delete.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- [OPIK-7306] [BE] fix: use GitHub username for migration 000103 changeset author
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- [OPIK-7306] [BE] fix: drop id_at predicate from SpanDAO retention paths
The spans retention range is keyed on trace_id, but id_at is materialized from
the span's own (client-assigned) UUIDv7 id, which can land in a later week than
its trace_id. A toMonday(id_at) bound derived from the trace-id range therefore
wrongly excludes valid candidates (spans orphaned on delete, undercount on
count). Filter by trace_id only on all three retention paths; keep migration
000103 as the prerequisite for the span read paths + partitioning cutover.Replace the id_at week-boundary tests with regression tests that give each span
an id weeks after its trace_id and assert it is still deleted/counted purely on
trace_id (guards against reintroducing an id_at bound).Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- [OPIK-7306] [BE] test: exercise span retention regression through executeRetentionCycle
Per review: don't call SpanDAO directly. Replace the direct-DAO span retention
tests with one that drives a full retention cycle via
RetentionPolicyService.executeRetentionCycle and asserts a span whose own id is a
later ISO week than its trace_id is still deleted (keyed on trace_id only). Drop
the now-unused SpanDAO injection.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- [OPIK-7306] [BE] chore: renumber spans id_at migration 000103 -> 000105
main merged 000103_add_config_to_cipx_spends and 000104_add_plan_to_cipx_trace_identities;
renumber the add_id_at_to_spans changeset to the next free slot (000105) to avoid a
duplicate liquibase changeset number. Update the SpanDAO javadoc reference.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
Co-authored-by: Claude Opus 4.8 (1M context) noreply@anthropic.com
下载附件