- Name
- lúc 23:27 23 tháng 9, 2026 UTC
- Tác giả
- Kamo
- Cam kết
- 31880e8
recordCreated wrote the CREATED row and then diffed the new lead against an empty snapshot, so every non-null starting field became a FIELD_CHANGED row — and the market and pool-entry keys, which carry their own event types, a MARKET_CHANGED and a MARKED_FOR_REASSIGNMENT row. Every intake lead therefore opened its History tab with ~20 rows restating the form it arrived with: 16.8M rows for 796K leads, 11M+ INSERTs per the database's own statistics. It also let a member earn the status-change achievement just by creating a lead (it reads FIELD_CHANGED on status). Creation now writes the CREATED row only; the lead itself is its starting state, and the first real change records the value it replaced in previous_value. **************** had the same shape (25 accounts, 227 rows) and follows the same rule. LeadHistoryServiceCreatedTest pins both halves (one row at creation; a later change keeps its previous value) and goes red with the old creation diff restored, as does the updated AccountHistoryServiceTest case. Takes effect as the lead-creating services rebuild: securityservice, daemonservice (intake processing), mediaservice (webinar registrations). Existing rows are untouched.