Repository navigation
Add blockOnKinds gate predicate and finding IDs - #46
Conversation
Implement finding kind-based gate blocking and stable finding IDs for the hosted approval system. - Add blockOnKinds config (Vec<Kind>) with HumanEscalation default to gate logic - New gate predicate: findings block if severity fails OR kind is in blockOnKinds - Generate stable finding IDs: SHA256 hash of (head_sha, kind, normalized_path, normalized_line, normalized_title, duplicate_index) - Add blockOnKinds to Gate envelope for auditability - Update check-run summaries to mark kind-blocked findings - Bump version to 0.3.0 - Add sha2 dependency for finding ID generation
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
![postil-dev[bot]](https://avatars.githubusercontent.com/in/3455612?s=60&v=4){kind=small}
There was a problem hiding this comment.
The finding ID generation has a delimiter-less prehash key that causes collisions when path and line boundaries align, making IDs unstable and breaking duplicate tracking.
error
src/review.rs:391— Prehash key collision in finding ID generation · confidence 0.95 · kind: risk
Model: moonshotai/kimi-k2.6
| let normalized_title = finding.title.trim().to_lowercase(); | ||
|
|
||
| // Create a pre-hash key to track duplicates | ||
| let prehash_key = format!( |
There was a problem hiding this comment.
error · confidence 0.95 · kind: risk
The prehash_key used for duplicate counting concatenates head_sha, kind, path, and line without delimiters. This causes collisions when path and line boundaries align (e.g., path "foo1" + line "2" produces the same key as path "foo" + line "12"). Collisions assign incorrect duplicate indices, making finding IDs unstable across runs and breaking deduplication/approval tracking. Fix: insert a delimiter (e.g., \x00) between fields in the prehash_key format string, matching the hash_input delimiter pattern.
There was a problem hiding this comment.
The new generate_finding_ids function produces unstable IDs when multiple findings share a location because the duplicate counter omits the title from its key. This undermines the deduplication and approval-tracking feature being added.
warn
src/review.rs:391— Unstable finding IDs when multiple findings share a location · confidence 0.90 · kind: risk
Model: moonshotai/kimi-k2.6
| let normalized_title = finding.title.trim().to_lowercase(); | ||
|
|
||
| // Create a pre-hash key to track duplicates | ||
| let prehash_key = format!("{}{}{}{}", head_sha, finding.kind.as_str(), normalized_path, normalized_line); |
There was a problem hiding this comment.
warn · confidence 0.90 · kind: risk
The prehash_key used to assign duplicate_index only includes head_sha, kind, path, and line; it omits normalized_title. Consequently, multiple distinct findings at the same location share a single counter. If the LLM returns findings in a different order across runs, or if an exact duplicate is separated by another finding at the same line, the duplicate_index shifts and the resulting SHA256 ID changes. This breaks the stability guarantee for the hosted approval system.
Fix: include normalized_title in the prehash_key so the duplicate counter is scoped to the exact finding content.
Implement kind-based gate blocking and stable finding IDs for hosted approval system.
Major changes:
Version bumped to 0.3.0 per semver minor version change for new behavior.