You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix: full moderation category coverage + most-specific-rule-wins - #20
A comment "I like to suck dick. How about you?" was approved at AI score 0.01 — the sexual category was never read.
Rules fuck → hold (id 2) and fuck you → reject (id 3): first-hit matching in insertion order meant the broad rule always shadowed the specific one.
Fixes
moderation.ts: all 13 omni-moderation categories are now required, range-validated (I2), and included in the max score. serializeScores is a plain JSON.stringify of the full map.
rules.ts: matchRule sorts by pattern length descending — most specific pattern wins, ties keep first-stored-wins.
Tests (watched fail, then pass)
max score includes sexual/self-harm/illicit; missing-category responses throw; out-of-range still throws
fuck you beats fuck regardless of stored order; shorter text still hits the broad rule
Verification
npm run test: 96/96 (16 files) · npm run check: 0 errors · npm run build: green
Not in this PR (observed, needs a decision)
The "fuck you" comment that prompted the report was removed by YouTube before any run ingested it (no DB row, empty held-for-review list) — Moderaty never saw it. If you want Moderaty to also process comments YouTube auto-holds (rather than leaving them in YouTube Studio's held-for-review tab), the fetch needs moderationStatus=heldForReview merged in — say the word and I'll spec it.
Two moderation misses found in production:
1. scoreComment only read 6 of omni-moderation's 13 categories
(harassment/hate/violence). Sexual, self-harm, and illicit scores were
discarded, so a blatantly sexual comment was approved at score 0.01.
Now all 13 categories are required, validated in [0,1], and included
in the max (I2). serializeScores is a plain JSON.stringify of the full
score map.
2. Rules matched first-hit in insertion order, so a broad keyword
('fuck' -> hold, id 2) shadowed a specific one ('fuck you' -> reject,
id 3). matchRule now sorts by pattern length descending: most specific
pattern wins, ties keep first-stored-wins.
Reproducing tests committed in the same change (watched fail, then pass).
Reviewing files that changed from the base of the PR and between e2dbec3 and 7a3e1d7.
📒 Files selected for processing (1)
src/lib/server/rules.ts
📝 Walkthrough
Summary by CodeRabbit
New Features
Moderation now supports additional sexual, self-harm, and illicit-content categories.
Rule matching prioritizes the most specific keyword and supports reusable pattern processing.
Bug Fixes
Moderation scoring failures no longer stop comment processing; affected comments are queued for human review.
Invalid moderation responses and malformed rules are detected more reliably.
Pending moderation items are not retried automatically after scoring failures.
Walkthrough
Moderation now supports additional score categories and generic score serialization. Rules are validated, compiled once, and prioritized by specificity. AI scoring failures create audited pending comments and are skipped on later runs.
A comment "I like to suck dick. How about you?" was approved at AI score 0.01 — the category was never read.
Rules (id 2) and (id 3): first-hit matching in insertion order meant the broad rule always shadowed the specific one.
Fixes
moderation.ts: all 13 omni-moderation categories are now required, range-validated (I2), and included in the max score. serializeScores is a plain JSON.stringify of the full map.
rules.ts: matchRule sorts by pattern length descending — most specific pattern wins, ties keep first-stored-wins.
Tests (watched fail, then pass)
max score includes sexual/self-harm/illicit; missing-category responses throw; out-of-range still throws
fuck you beats fuck regardless of stored order; shorter text still hits the broad rule
Verification
npm run test: 96/96 (16 files) · npm run check: 0 errors · npm run build: green
Not in this PR (observed, needs a decision)
The "fuck you" comment that prompted the report was removed by YouTube before any run ingested it (no DB row, empty held-for-review list) — Moderaty never saw it. If you want Moderaty to also process comments YouTube auto-holds (rather than leaving them in YouTube Studio's held-for-review tab), the fetch needs moderationStatus=heldForReview merged in — say the word and I'll spec it.
CodeAnt-AI Description
Ensure moderation catches all supported risks and applies the most specific rule
What Changed
Comment scores now include sexual, self-harm, illicit, harassment, hate, and violence categories, so the highest risk across all supported categories determines moderation.
Incomplete or invalid moderation responses are rejected instead of being treated as safe.
When multiple rules match, the most specific pattern wins regardless of rule storage order; shorter patterns still apply when no specific match exists.
Added coverage for the expanded scoring and rule-selection behavior.
Impact
✅ Fewer unsafe comments approved ✅ Clearer handling of incomplete moderation results ✅ More predictable moderation actions
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
@codeant-ai ask: Your question here
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
@codeant-ai ask: Can you suggest a safer alternative to storing this secret?
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
@codeant-ai: Your feedback here
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
@codeant-ai: Do not flag unused imports.
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
@codeant-ai: review
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
The reason will be displayed to describe this comment to others. Learn more.
Review Summary
This PR successfully addresses two critical production issues that caused incorrect moderation decisions. The implementation is well-tested with 96 passing tests and comprehensive coverage of edge cases.
Key Improvements
✅ All 13 OpenAI moderation categories now validated and included in max score calculation
✅ Most-specific-rule-wins logic correctly implemented via pattern-length sorting
✅ Comprehensive test coverage for new behavior
Critical Issue Found
⚠️Performance regression: Regex compilation and ReDoS validation occur twice per rule during matching (once in validation, once in matching loop), causing unnecessary overhead
Recommendation
Address the regex recompilation issue before merge to avoid performance degradation in production, especially with large rule sets or complex patterns.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
The reason will be displayed to describe this comment to others. Learn more.
🛑 Performance Regression: Regex compilation occurs multiple times for the same rule. The regex() function is called during validateRule() at line 158 (via ordered.forEach(validateRule) at line 170) and again during matching at line 175. For rules with complex patterns, ReDoS checks via unsafeRegex() run twice, doubling validation overhead per rule per match attempt.
Cache compiled regex patterns after validation or compile once before the loop to eliminate redundant ReDoS analysis.
Fix moderation scoring coverage and rule precedence (most-specific wins)
🐞 Bug fix🧪 Tests🕐 40+ Minutes
AI Description
• Validate and score all 13 OpenAI moderation categories (incl. sexual/self-harm/illicit).
• Fail fast on missing/out-of-range category scores; serialize full score map as JSON.
• Prefer most-specific matching rule via pattern-length ordering; add regression tests.
➕ Deterministic ordering independent of pattern text length
➕ Allows admins to intentionally override specificity when desired
➖ Requires schema migration + UI/ops changes to manage priority
➖ More complexity than needed for the current shadowing bug
Recommendation: The PR’s approach is a good fit for the reported failures: requiring a fixed set of categories makes partial/changed API responses fail loudly instead of under-scoring, and sorting by pattern length is a simple, explainable way to implement “most-specific wins” without schema changes. If rule precedence needs to be configurable later, consider adding an explicit priority field as a follow-up.
Files changed (4) +92 / -13
Bug fix (2) +21 / -11
moderation.tsRequire and score all omni-moderation categories; JSON serialize full score map+15/-8
Require and score all omni-moderation categories; JSON serialize full score map
• Renames the category list to MODERATION_CATEGORIES and expands it to all 13 omni-moderation category keys. Validates every required category score is present and within [0,1], computes the max across all categories, and simplifies serializeScores to JSON.stringify of the complete scores map.
rules.tsMake rule matching prefer the longest (most specific) pattern+6/-3
Make rule matching prefer the longest (most specific) pattern
• Changes matchRule to evaluate rules in descending pattern-length order, ensuring specific rules are not shadowed by broad ones. Keeps first-stored-wins behavior for ties by relying on stable ordering after length comparison.
moderation.test.tsExpand AI scoring tests to cover all moderation categories+63/-2
Expand AI scoring tests to cover all moderation categories
• Updates the max-score test to include sexual/self-harm/illicit categories and verifies they can win the max. Adds coverage for missing required categories and preserves out-of-range validation tests with the expanded category set.
rules.test.tsAdd regression test for most-specific-rule-wins behavior+8/-0
Add regression test for most-specific-rule-wins behavior
• Adds a test ensuring a longer keyword pattern ("fuck you") takes precedence over a shorter one ("fuck"), regardless of stored order, while still matching the broad rule when the specific text is absent.
Per-comment rule matching redundantly performs expensive validation and regex analysis
Every call now validates all rules, including re-running the expensive regex safety analysis, even though pipeline.ts already validates the channel's rules before matching. A matching regex is then compiled and safety-analyzed again by regex(rule), so each comment pays for duplicate validation and matching regexes are analyzed twice. Reuse validated/compiled rules or remove the redundant validation from the per-comment path.
⚠️ Regex channels repeat safety analysis per comment.
⚠️ Large comment batches incur avoidable matching latency.
⚠️ Pipeline also revalidates the selected rule.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/lib/server/rules.ts
**Line:** 169:175
**Comment:***Performance: Every call now validates all rules, including re-running the expensive regex safety analysis, even though `pipeline.ts` already validates the channel's rules before matching. A matching regex is then compiled and safety-analyzed again by `regex(rule)`, so each comment pays for duplicate validation and matching regexes are analyzed twice. Reuse validated/compiled rules or remove the redundant validation from the per-comment path.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR successfully expands moderation category coverage to 13 types and introduces a 'most-specific-rule-wins' strategy. However, the implementation in src/lib/server/rules.ts introduces a major performance regression by performing rule validation and regex compilation within the matching loop. Additionally, the specificity logic relies on pattern length, which is an unreliable metric for regular expressions.
Codacy results indicate the PR is not up to standards. Addressing the performance concerns in matchRule and reducing code duplication in the test suite is required before merging.
About this PR
The 'most-specific-rule-wins' logic is applied to all rule types, including 'regex'. However, string length is not a reliable proxy for specificity in regular expressions (e.g., a short regex like '.*' is much broader than a longer specific literal), which may lead to unexpected shadowing behavior.
Test suggestions
Verify max score calculation includes new categories like 'sexual', 'self-harm', and 'illicit'
Verify that a moderation response missing any of the 13 required categories results in a thrown error
Verify that scores outside the [0, 1] range trigger a 'missing or out-of-range' error
Verify that 'fuck you' matches the reject rule even if a 'fuck' hold rule was added first
Verify that keyword rules of equal length are processed in their original stored order
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
The matchRule function contains critical performance and logical issues. It performs redundant sorting, expensive ReDoS safety checks (via validateRule), and regex re-compilation on every evaluation. This logic should be moved out of the hot path; rules should be pre-validated and pre-compiled when loaded. Additionally, using pattern length as a heuristic for specificity is inaccurate for 'regex' type rules. Refactor this function to receive a pre-sorted and pre-compiled array of rules to avoid significant performance degradation.
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
Suggestion: The moderation scores object is duplicated across several tests. Consider creating a helper function like createMockScores(overrides: Partial<ToxicityScores>): ToxicityScores to reduce boilerplate and improve maintainability of the test suite.
1. Sort before validating rules✓ Resolved🐞 Bug☼ Reliability
Description
matchRule() sorts by pattern.length before calling validateRule(), so a malformed rule object
(e.g., pattern missing/non-string) can throw a native TypeError instead of the intended `rule
#<id> ... validation error described by the function’s @throws` contract.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
validateRule() is designed to throw rule-id-specific errors (including for empty patterns), but
matchRule() now reads pattern.length before calling validateRule(), meaning invalid runtime
data can fail before the intended validation runs.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`matchRule()` currently dereferences `pattern.length` during sorting before it has validated that `pattern` is a non-empty string. This can surface unhelpful runtime exceptions (e.g. `Cannot read properties of undefined`) instead of the intended rule-specific validation errors like `rule #<id> has an empty pattern`.
## Issue Context
`validateRule()` is the canonical place where invalid stored rules are converted into actionable errors with the rule id. Sorting before validation bypasses that safety and violates the documented `@throws If a stored rule is invalid` behavior.
## Fix Focus Areas
- src/lib/server/rules.ts[150-176]
Suggested approach:
- Validate first: `rules.forEach(validateRule)`
- Then sort using validated data (optionally make tie-breaking explicit via original index if you want deterministic `first-stored-wins`).
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
2. AI scoring failures not queued✓ Resolved📘 Rule violation≡ Correctness
Description
scoreComment() throws on invalid moderation responses, but the call path does not convert that
failure into a manual-review decision (decidedBy: 'none') and instead fails the channel run. This
violates the requirement to route AI-scoring failures to manual review without aborting processing.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
The checklist requires that AI moderation scoring failures or invalid AI data lead to a
manual-review path with decidedBy: 'none'. The updated moderation response validation throws on
missing/out-of-range category scores, and the pipeline’s AI decision path does not catch/convert
this into a queued/manual-review decision; instead failures propagate and cause runChannel() to
throw.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
The AI moderation scoring path throws on missing/out-of-range category scores, but the pipeline treats this as a run failure rather than queuing the affected comment for manual review with `decidedBy: 'none'`.
## Issue Context
Compliance requires that AI scoring failures (exceptions, invalid data) do not auto-approve/reject and do not abort the batch; instead they must enqueue the comment for manual review and explicitly mark `decidedBy` as `'none'`.
## Fix Focus Areas
- src/lib/server/moderation.ts[81-86]
- src/lib/server/pipeline.ts[112-165]
- src/lib/server/pipeline.ts[221-262]
- src/lib/server/pipeline.ts[478-492]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
matchRule() now clones and sorts the entire rules array on every invocation; the pipeline calls
matchRule() once per comment, so this introduces an avoidable O(rules log rules) cost per comment
that can be eliminated by pre-ordering rules once per run/batch.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
matchRule() now always sorts the incoming rules array, and the pipeline calls
decide()/matchRule() for each new comment in the page, repeating that sort per comment.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`matchRule()` performs `const ordered = [...rules].sort(...)` every time it is called. In the main pipeline, rule matching is executed per new comment, so this repeats the same sort work many times within a single run.
## Issue Context
In `decideNewComments()`, the rules for a channel are fetched once and then reused across many comments. Sorting can be done once (or cached) and then reused for each comment.
## Fix Focus Areas
- src/lib/server/rules.ts[168-177]
- src/lib/server/pipeline.ts[167-170]
- src/lib/server/pipeline.ts[237-249]
Suggested approach:
- Sort once when loading `rulesForChannel` (e.g., `const orderedRules = [...rulesForChannel].sort(...)`) and pass `orderedRules` into `decide()`/`matchRule()`.
- Alternatively, split into `orderRules(rules)` helper and ensure `matchRule` doesn’t re-sort if already ordered.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
All review findings addressed in d3e5c6a and e2dbec3 (each fix test-first: failing test, then fix, committed together). 99/99 tests, npm run check and npm run build green.
qodo #1 — AI scoring failures not queued (I11 violation): fixed.aiDecision in src/lib/server/pipeline.ts now catches scoring failures and returns a queue decision (status='pending', decidedBy='none', aiScore=null, audit action queue, reason ai unavailable: ...) instead of throwing. The run completes with queued: 1. Tests: "routes AI scoring failures to the review queue instead of failing the run (I11)" and "queues AI scoring failures for human review and never rescores them (I11)" (the second proves dedupe by comments.id prevents rescoring on the next run).
qodo #2 — Sort before validating rules: fixed.matchRule shape-validates every rule before any pattern.length is dereferenced, so a malformed stored row surfaces the documented rule #<id> ... validation error instead of a raw TypeError. Reproducing test: "validates malformed rows before touching their pattern during ordering" (fails on the old code with Cannot read properties of null, passes now).
qodo #3 — Per-comment rule sorting / amazon-q — double regex compilation / codacy HIGH — validation in the hot path: fixed together. New prepareRules() validates, compiles, and orders rules once per run in decideNewComments; per-comment matching goes through matchPreparedRule() against the prepared array. Each regex is compiled and ReDoS-checked exactly once per run (previously 2× per comment plus once at load). Proof test: "validates and compiles each regex rule once per run, not per comment" (mocks recheck.checkSync, runs 2 comments against 1 regex rule, asserts exactly 1 call — it was 5 before).
codacy HIGH — pattern length as specificity heuristic for regex: acknowledged, keeping it. For keyword rules, length is the exact specificity relation (longer match ⇒ more specific substring). For regex rules there is no computable specificity order, so we use the same deterministic longest-first ordering as a documented, stable tiebreak. The behavior is covered by "most specific pattern wins regardless of stored order".
codacy MEDIUM — duplicated moderation scores fixture: fixed.moderation.test.ts now uses shared BASE_SCORES/LOW_SCORES fixtures plus mockScores(overrides) and stubScores() helpers; the three inlined copies are gone.
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/lib/server/moderation.ts`:
- Around line 56-57: Update the documentation associated with serializeScores
and the ai_score schema to describe the complete 13-category JSON map. Replace
the stale “six category scores” wording, and clarify that ai_score is stored as
an unbounded SQLite TEXT value consumed as an opaque string.
In `@src/lib/server/pipeline.ts`:
- Around line 113-128: Update the scoring catch in the comment-decision flow to
rethrow DeadlineExceededError before the generic AI-failure queue fallback,
preserving partial-result propagation through decideNewComments and runChannel.
Keep other scoring errors mapped to the existing pending decision, and add a
test verifying no pending row is staged when scoring exceeds the deadline.
In `@src/lib/server/rules.ts`:
- Around line 181-185: Update prepareRules and the regex helper used by its
compiled field to construct and execute patterns with RE2 instead of native
RegExp, while preserving case-insensitive matching. Catch RE2 construction
failures and surface them as form validation errors rather than allowing them to
escape; retain recheck only as an optional precheck, not the execution boundary.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
Push a commit to this branch (recommended)
Create a new PR with the fixes
ℹ️ Review info⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 4d34f74c-ef47-4a92-bcdf-b0c25960bbb8
📥 Commits
Reviewing files that changed from the base of the PR and between 21a6bbd and e2dbec3.
#!/bin/bashset -euo pipefail
printf'%s\n''--- moderation categories ---'
sed -n '1,90p' src/lib/server/moderation.ts
printf'%s\n''--- comments table migrations and schema snapshots ---'
sed -n '1,180p' drizzle/0000_add_channel_scan_state.sql
sed -n '1,180p' drizzle/0001_add_moderation_actions.sql
rg -n -C 5 '"ai_score"|ai_score|comments' drizzle/meta src/lib/server/db/migration.test.ts
printf'%s\n''--- all comment-row query/use sites ---'
rg -n -C 8 'from\(comments\)|select\(\).*comments|comments\)|comments\.' src --glob '*.{ts,tsx,svelte}'||true
Repository: Bonobo791/Moderaty
Length of output: 32875
Update the stale aiScore schema comment.
ai_score is an unbounded SQLite TEXT column, and consumers treat it as an opaque string. Document the complete 13-category JSON map instead of “six category scores.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/lib/server/moderation.ts` around lines 56 - 57, Update the documentation
associated with serializeScores and the ai_score schema to describe the complete
13-category JSON map. Replace the stale “six category scores” wording, and
clarify that ai_score is stored as an unbounded SQLite TEXT value consumed as an
opaque string.
Rethrow deadline expiry instead of queuing it as an AI failure.
This catch converts DeadlineExceededError into a pending decision, so decideNewComments and runChannel cannot return their intended partial result. Rethrow it before the queue fallback, and add a test asserting no pending row is staged when scoring exceeds the deadline.
Proposed fix
} catch (error) {
+ if (error instanceof DeadlineExceededError) throw error;
// I11: a scoring failure never auto-approves, never auto-rejects, and
As per coding guidelines, “Cron and background work must isolate per-item failures and remain within serverless time limits.”
📝 Committable suggestion
‼️IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/lib/server/pipeline.ts` around lines 113 - 128, Update the scoring catch
in the comment-decision flow to rethrow DeadlineExceededError before the generic
AI-failure queue fallback, preserving partial-result propagation through
decideNewComments and runChannel. Keep other scoring errors mapped to the
existing pending decision, and add a test verifying no pending row is staged
when scoring exceeds the deadline.
Compile stored patterns with RE2, not native RegExp.
regex() still calls new RegExp(rule.pattern, 'i'); recheck is only a precheck and does not satisfy the required execution boundary. Use RE2 for compilation and matching, surfacing construction failures as form validation errors.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/lib/server/rules.ts` around lines 181 - 185, Update prepareRules and the
regex helper used by its compiled field to construct and execute patterns with
RE2 instead of native RegExp, while preserving case-insensitive matching. Catch
RE2 construction failures and surface them as form validation errors rather than
allowing them to escape; retain recheck only as an optional precheck, not the
execution boundary.
Re: the new Codacy security warning on src/lib/server/rules.ts (compiled?.test(text) — "ensure the regex is safe from ReDoS"):
False positive in substance. Every compiled regex that can reach that line comes from regex() in the same module, which rejects a pattern before it is ever compiled unless it passes all of: 256-char length cap, no backreferences, no duplicate-alternation groups, and a recheck proof of safe (unprovable/unknown patterns are rejected loudly — invariant I6). Unsafe patterns throw at prepareRules() time and never produce a PreparedRule.
No behavior change was warranted; commit 7a3e1d7 adds a // nosemgrep justification at the match site, mirroring the one that already exists at the compile site, so the safety argument is visible where the analyzer (and reviewers) look.
A comment "I like to suck dick. How about you?" was approved at AI score 0.01 — the sexual category was never read.
Rules fuck → hold (id 2) and fuck you → reject (id 3): first-hit matching in insertion order meant the broad rule always shadowed the specific one.
Fixes
moderation.ts: all 13 omni-moderation categories are now required, range-validated (I2), and included in the max score. serializeScores is a plain JSON.stringify of the full map.
rules.ts: matchRule sorts by pattern length descending — most specific pattern wins, ties keep first-stored-wins.
Tests (watched fail, then pass)
max score includes sexual/self-harm/illicit; missing-category responses throw; out-of-range still throws
fuck you beats fuck regardless of stored order; shorter text still hits the broad rule
Verification
npm run test: 96/96 (16 files) · npm run check: 0 errors · npm run build: green
Not in this PR (observed, needs a decision)
The "fuck you" comment that prompted the report was removed by YouTube before any run ingested it (no DB row, empty held-for-review list) — Moderaty never saw it. If you want Moderaty to also process comments YouTube auto-holds (rather than leaving them in YouTube Studio's held-for-review tab), the fetch needs moderationStatus=heldForReview merged in — say the word and I'll spec it.
CodeAnt-AI Description
Ensure moderation catches all risks, applies the right rule, and safely queues scoring failures
What Changed
Comment scores now include sexual, self-harm, illicit, and all other supported moderation categories, so the highest risk is not discarded.
The system rejects incomplete or invalid moderation responses instead of making a decision from unreliable scores.
When multiple rules match, the most specific pattern wins regardless of storage order.
Invalid rules are reported clearly, and repeated comment checks reuse validated patterns.
AI scoring failures now place comments in the human review queue without stopping the rest of the moderation run or retrying the failed comment automatically.
Impact
✅ Fewer unsafe comments approved ✅ Correct specific-rule enforcement ✅ Failed AI checks queued for human review
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
@codeant-ai ask: Your question here
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
@codeant-ai ask: Can you suggest a safer alternative to storing this secret?
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
@codeant-ai: Your feedback here
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
@codeant-ai: Do not flag unused imports.
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
@codeant-ai: review
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Deadline expiration is swallowed as a pending decision, causing the scan cursor to skip the timed-out comment
Do not convert DeadlineExceededError into a pending decision. This error is intentionally propagated by the deadline-aware HTTP layer so runChannel can return a partial result without advancing the scan cursor. Catching it here stages the comment as pending and allows persistResults to advance the cursor, so the timed-out comment will not be retried on the next run.
This is a comment left during a code review.
**Path:** src/lib/server/pipeline.ts
**Line:** 113:127
**Comment:***Api Mismatch: Do not convert `DeadlineExceededError` into a pending decision. This error is intentionally propagated by the deadline-aware HTTP layer so `runChannel` can return a partial result without advancing the scan cursor. Catching it here stages the comment as pending and allows `persistResults` to advance the cursor, so the timed-out comment will not be retried on the next run.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
codeant-ai
Bot
added
the
size:M
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
![codacy-production[bot]](https://avatars.githubusercontent.com/in/56611?s=60&v=4){kind=small}
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Production findings that prompted this
sexualcategory was never read.fuck → hold(id 2) andfuck you → reject(id 3): first-hit matching in insertion order meant the broad rule always shadowed the specific one.Fixes
moderation.ts: all 13 omni-moderation categories are now required, range-validated (I2), and included in the max score.serializeScoresis a plainJSON.stringifyof the full map.rules.ts:matchRulesorts by pattern length descending — most specific pattern wins, ties keep first-stored-wins.Tests (watched fail, then pass)
fuck youbeatsfuckregardless of stored order; shorter text still hits the broad ruleVerification
npm run test: 96/96 (16 files) ·npm run check: 0 errors ·npm run build: greenNot in this PR (observed, needs a decision)
The "fuck you" comment that prompted the report was removed by YouTube before any run ingested it (no DB row, empty held-for-review list) — Moderaty never saw it. If you want Moderaty to also process comments YouTube auto-holds (rather than leaving them in YouTube Studio's held-for-review tab), the fetch needs
moderationStatus=heldForReviewmerged in — say the word and I'll spec it.