PERCENTAGE_SPLIT: implement engine's 1-in-9999 recursion edge case in SQL

オープン
#4 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
python, sql
領域
databases

調査の方向性

PERCENTAGE_SPLIT の inline SQL 実装を特定し、bare-hash の処理を issue に記載されているエンジンのセマンティクスと比較してください。bare_hash_mod = 9998 に対する入力倍増の再帰を 2-3 回の反復に制限して実装・検証し、通常の入力で既存の結果が維持されることを確認してください。

索引モデルが issue の本文から書いたものです。

説明

The pure-SQL PERCENTAGE_SPLIT hash diverges from the engine on the ~1/9999 inputs where the bare hash mod 9999 == 9998 (the engine recurses with doubled input; this implementation skips).

Real-world impact at typical thresholds: ~0.005% false-negative rate on the count of identities matching a percentage-split segment. At 870M with threshold 50, that's ~22k false-negatives across the env — a rounding error on a count-badge UI but a measurable bias if anyone uses the count for billing or contract decisions.

What to ship

Implement the recursion as a CASE WHEN bare_hash_mod = 9998 THEN <recursive hash> ELSE <main hash> END wrapper in the inline SQL. The recursive hash uses doubled input: seg_key || ',' || value || ',' || seg_key || ',' || value. Cap at 2-3 iterations (engine recurses arbitrarily but in practice the second iteration almost always lands at non-9998).

Why deferred

Sub-0.005% bias on a UI count is below the threshold that customers care about. Defer until a customer reports a discrepancy or until the engine's bucketing semantics change.

主要言語
Python
スター
1
フォーク
0
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Flagsmith/flagsmith-sql-flag-engine のほかの issue

Flagsmith/flagsmith-sql-flag-engine の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。