Both tables are ReplacingMergeTree; dedup happens only during background part
merges, not at read time. The ongoing etl_rw feed keeps inserting into pf_board,
so right after an insert that updates an existing row there is a short window
(before the forced merge, min_age_to_force_merge_seconds=15) where the same
task_id / board_key exists in two parts. A plain SELECT reads both parts and
returns the row twice.
The /api/boards query already collapses duplicates via argMax + GROUP BY, but
/api/bookings and the two /api/map queries read raw rows, so they could
intermittently double a booking (timeline/balloon) or a surface marker.
Add FINAL to those three reads (pf_board in bookings + map current, board_info
in map surfaces). At 463/515 rows the cost is negligible and it removes the
class of transient duplicates regardless of merge timing. Output verified
unchanged against the single-part baseline.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Planfix has emitted manager names in two word orders over time ("Имя Фамилия"
from the 26 Jul 2026 n8n backfill, "Фамилия Имя" from the ongoing etl_rw feed),
so one person appeared as two distinct filter options (e.g. "Александра Столбова"
vs "Столбова Александра"), splitting their tasks across two facet values.
Fix without touching stored data:
- MANAGER_KEY_ARR: SQL expression building a word-order- and case-independent
key (lowercase, split, arraySort, rejoin) per manager array element.
- MANAGER_COND / MAP_MANAGER_COND now match on that key, so a selected manager
catches rows stored under either order.
- parse_filters normalizes incoming manager values with the same key (_mkey).
- /api/meta returns canonical "Фамилия Имя" names (CANONICAL_MANAGERS),
deduplicated; unknown names pass through unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
