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
Logging was already complete (audit_log covers pipeline, queue, and dry-run actions); this PR adds reversibility:
The audit log now shows an Undo button on the latest action per comment when it's reversible: hold/reject restore the comment at YouTube via setModerationStatus(..., 'published'); ban offers "Undo comment" (the comment is restored — YouTube has no API to lift an author ban); delete offers nothing (permanent).
The undo action follows the queue page's established pattern: atomic conditional claim on the comment (concurrent submissions single-winner, loser 404s), DB before the remote call (I3), claim released on YouTube failure so the restore stays retryable, loud errors only. DRY_RUN=true records a dry-run audit row and makes no YouTube call (I8). Every undo writes a restore audit row naming the original action (derived server-side).
A restored comment becomes approved/human.
Disclosure (per review feedback):
Terms §9.4 states what's logged and exactly what cannot be reversed (deletes, author bans) → LEGAL_VERSION bumped to 1.3, so existing users re-accept via the established /consent flow on next login.
New Help tab in the app nav with a plain-language reversibility matrix matching Terms §9.4.
New coverage: undo restore/ban/404/release-on-failure/dry-run/401/404-ownership/400, load undoable flags, published API params, Terms §9.4 disclosure guard, Help tab presence + copy.
Notes
No schema migration (audit action and comment status are free-text enums; comment updated).
Author-unban is impossible via the YouTube API — disclosed in Terms + Help, not faked as functionality.
CodeAnt-AI Description
Add reversible moderation actions through the audit log
What Changed
Users can undo the latest hold or reject action from the audit log, restoring the comment on YouTube and marking it approved.
Undoing a ban restores the comment but clearly leaves the author ban in place; deleted comments remain permanent.
Audit entries now show undo controls only for the latest eligible action, with reliable ordering when actions share a timestamp.
Failed or interrupted restores remain retryable, and dry-run restores are recorded without contacting YouTube.
Added Help guidance and Terms disclosure explaining which moderation actions can and cannot be reversed.
Impact
✅ Restore held or rejected comments from the audit log ✅ Retry interrupted restores without losing the action ✅ Clearer limits for bans and deletions
💡 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.
Added Undo controls for reversible hold, reject, and ban actions in the audit log.
Added comment-only restoration when an author ban cannot be reversed.
Added restoration status and success or error feedback.
Added a Help page covering moderation workflows, audit logs, and action reversibility.
Added a Help link to the application navigation.
Documentation
Updated Terms of Service disclosures for audit logging and irreversible deletions or bans.
Updated the legal document version to 1.3.
Walkthrough
The change adds audit-log undo actions for held, rejected, and banned comments. It restores comments through YouTube when possible, records restore outcomes, adds UI controls and Help content, and updates Terms §9 and the legal version.
Changes
Audit Log Undo Flow
Layer / File(s)
Summary
Restoration contract and audit action src/lib/server/youtube.ts, src/lib/server/youtube.test.ts, src/lib/server/db/schema.ts
setModerationStatus accepts published for restoration. The schema documents the restoring status and restore audit action. Tests verify the YouTube request parameters.
The loader marks only current reversible actions as undoable. The undo action validates access, claims comments atomically, restores them, handles failures and dry runs, and records audit entries.
Undo controls and Help page src/routes/(app)/+layout.svelte, src/routes/(app)/channels/[id]/log/+page.svelte, src/routes/(app)/help/*
The audit log renders full or comment-only restoration controls. Navigation exposes Help content that describes reversible and permanent actions.
Legal disclosure and version src/lib/components/landing/legal/Terms.svelte, src/lib/landing/legal.ts, src/lib/landing/legal.test.ts
Terms §9 documents audit logging and action permanence. The shared legal version changes to 1.3, with regression coverage.
sequenceDiagram
actor Moderator
participant AuditLogPage
participant UndoAction
participant Database
participant YouTubeAPI
Moderator->>AuditLogPage: Submit undo with commentId
AuditLogPage->>UndoAction: Authenticate and validate request
UndoAction->>Database: Claim reversible comment
UndoAction->>YouTubeAPI: Set moderationStatus=published
YouTubeAPI-->>UndoAction: Return restoration result
UndoAction->>Database: Update comment and record restore audit entry
UndoAction-->>AuditLogPage: Return success or failure
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.
Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name
Status
Explanation
Title check
✅ Passed
The title identifies moderation logging and undo functionality, which are central changes, but it overstates reversibility because deletes and author bans cannot be reversed.
Description check
✅ Passed
The description clearly explains the audit-log undo behavior, irreversible actions, retry handling, disclosures, and verification coverage.
Linked Issues check
✅ Passed
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
✅ Passed
Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches 💡 2📝 Generate docstrings 💡
Create stacked PR
Commit on current branch
🛠️ Fix failing CI checks 💡
Create stacked PR
Commit on current branch
🧪 Generate unit tests (beta)
Create PR with unit tests
Commit unit tests in branch feat-reversible-actions
Comment @coderabbitai help to get the list of available commands.
This PR adds undo for the latest hold, reject, or ban action shown in the audit log. The backend claims the comment, restores it on YouTube when enabled, and records the restore action.
sequenceDiagram
participant User
participant Audit Log
participant Backend
participant Database
participant YouTube
User->>Audit Log: Select Undo
Audit Log->>Backend: Submit comment restore
Backend->>Database: Claim and mark comment approved
Backend->>YouTube: Restore comment as published
YouTube-->>Backend: Restore confirmed
Backend->>Database: Record restore audit action
Backend-->>Audit Log: Show restore success
• Add reversible “Undo” flows for held/rejected (and comment-only for bans) actions.
• Implement server-side undo with atomic DB claim, YouTube restore call, and audit logging.
• Disclose irreversible actions in Terms/Help and force re-consent via legal version bump.
Diagram
graph TD
U["Audit log page"] --> L["load() marks undoable"] --> DB[("SQLite DB")]
U --> A["undo action"] --> DB --> YT{{"YouTube API"}} --> DB
U --> LEG["Terms & Help disclosure"]
subgraph Legend
direction LR
_ui["UI/Page"] ~~~ _db[("Database")] ~~~ _ext{{"External API"}}
end
Loading
High-Level Assessment
The following are alternative approaches to this PR:
1. Outbox/job-based undo (async restore worker)
➕ Avoids holding request open on slow/failed YouTube calls
➕ Natural retry/backoff and observability for restore attempts
➕ Can guarantee DB/remote consistency via durable workflow
➖ More infrastructure (queue/worker) and operational complexity
➖ User experience becomes eventual-consistency (undo may complete later)
➖ More code paths to test (enqueue, process, reconcile)
2. Explicit undo token / idempotency key per audit row
➕ Makes undo strictly idempotent and easier to reason about
➕ Eliminates reliance on comment status as the only concurrency gate
➖ Current 200-row limit likely makes this premature optimization
Recommendation: Keep the current approach: computing undoability at load-time and using an atomic conditional DB claim before calling YouTube is a good fit for the synchronous, user-initiated undo UX. It minimizes schema churn, prevents concurrent double-undos, and correctly keeps the restore retryable by releasing the claim on remote failure; the heavier outbox/worker alternative is only worth it if YouTube failures/latency become a frequent operational issue.
Files changed (13) +455 / -11
Enhancement (4) +121 / -8
youtube.tsAllow setModerationStatus('published') for undo restores+5/-1
Allow setModerationStatus('published') for undo restores
• Extends setModerationStatus to accept 'published' as a valid status to restore held/rejected comments. Adds documentation clarifying that deletes and author bans remain irreversible due to YouTube API limitations.
+page.server.tsCompute undoable audit entries and implement undo action+88/-3
Compute undoable audit entries and implement undo action
• Enhances audit log load to mark only the latest reversible action per comment as undoable (full for hold/reject, comment-only for ban). Adds an undo server action that atomically claims the comment in DB, restores it on YouTube (unless DRY_RUN), releases the claim on failure, and records a restore/dry-run audit row with server-derived prior action naming.
+page.svelteRender Undo controls and restore status in audit log UI+27/-4
Render Undo controls and restore status in audit log UI
• Adds an Undo column with per-row forms for reversible actions and differentiates full undo vs comment-only undo for bans. Adds flash messaging for undo results and treats 'restore' as an OK badge state.
legal.test.tsAdd Terms disclosure guard tests for irreversibility claims+9/-0
Add Terms disclosure guard tests for irreversibility claims
• Adds a test ensuring the Terms include audit-log logging and explicitly disclose that deletes and author bans cannot be undone. Prevents shipping an undo UX without accurate legal disclosure.
youtube.test.tsTest restoring comments via moderationStatus=published+12/-0
Test restoring comments via moderationStatus=published
• Adds a unit test asserting setModerationStatus sends moderationStatus=published and banAuthor=false when restoring a comment. Ensures the undo path uses the expected YouTube API parameters.
actions.test.tsAdd comprehensive tests for undo action behavior+151/-0
Add comprehensive tests for undo action behavior
• Introduces tests covering successful restores, ban undo naming, 404 for deleted comments, claim release on YouTube failure, DRY_RUN behavior, 401 when signed out, 404 for non-owned channel, and 400 for missing commentId. Mocks YouTube and env dependencies while asserting DB state and audit log writes.
load.test.tsTest undoable flagging on audit log load+38/-1
Test undoable flagging on audit log load
• Adds a test ensuring only the latest action per comment is marked undoable and that restore/approve and superseded actions are not undoable. Expands test seeding to include audit_log rows.
help.test.tsTest Help tab presence and disclosure consistency+43/-0
Test Help tab presence and disclosure consistency
• Adds tests verifying the Help link exists in app nav and that the Help page copy matches the Terms disclosure (permanence of deletes and author bans). Also asserts that the audit log is referenced for undoing holds/rejects.
Terms.svelteDisclose irreversible moderation actions in Terms §9.4+2/-0
Disclose irreversible moderation actions in Terms §9.4
• Adds a new Terms section explicitly stating all moderation actions are logged and clarifying which actions can/cannot be reversed. Documents that deletes and author bans are permanent due to missing YouTube API support.
schema.tsDocument new audit_log action value: restore+1/-1
Document new audit_log action value: restore
• Updates the audit_log.action comment to include the new 'restore' action value used for undo operations. No schema migration is introduced; this is a documentation-level update for the free-text enum usage.
+page.svelteAdd Help page with reversibility matrix+77/-0
Add Help page with reversibility matrix
• Creates a Help page explaining moderation behavior, the audit log, and a clear matrix of which actions can be undone. Explicitly states that deletes and author bans are permanent and links back to Terms §9.4.
The reason will be displayed to describe this comment to others. Learn more.
The reversibility feature is well-implemented with proper authorization, atomic operations, error handling, and audit logging. The code follows established patterns (claim-before-call, release-on-failure) and includes comprehensive test coverage (289 tests). The legal disclosure updates and help documentation appropriately document the limitations of YouTube's API (author bans cannot be lifted).
Note: I flagged one concern about the status check logic, but upon further analysis the implementation appears correct - when YouTube bans a comment it sets the status to rejected, which the check on line 79 properly handles. Please verify this behavior matches YouTube's actual API response for banned comments.
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.
🛑 Logic Error: The undo handler rejects ban actions despite the UI marking them as undoable. Lines 48-52 flag ban actions as undoable='comment-only', but line 79 only accepts held or rejected status. When a user bans a comment, YouTube sets it to rejected status, but this check doesn't account for the fact that the latest action in the audit log is ban, not reject. If the comment status changed between the ban and the undo attempt, this will incorrectly throw 404 for legitimate undo requests.
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR successfully implements an 'undo' feature for moderation actions with atomic database updates and YouTube API integration. However, Codacy results indicate the PR is not up to standards due to increased code cloning in the test suites. Two primary issues should be addressed before merging: the logic for displaying the 'Undo' button in the audit log is currently too strict, as it only checks the absolute latest log entry, potentially hiding the button if a non-state-changing action (like a dry-run) occurs. Additionally, the server-side action for undoing moderation should return a fail response rather than throwing an error to prevent full-page crashes and allow the UI to display the error message.
Test suggestions
Verify YouTube API call uses 'published' status and no author ban for restorations\n- [x] Verify successful undo of a rejected comment updates DB to 'approved' and inserts 'restore' log\n- [x] Verify undo of a 'ban' correctly restores the comment and names 'ban' in the audit reason\n- [x] Verify undo attempt on a deleted comment results in a 404 error and no change\n- [x] Verify that a YouTube API failure reverts the DB status to the original state (releasing the claim)\n- [x] Verify DRY_RUN mode correctly bypasses the API and records a 'dry-run' action\n- [x] Verify audit log loading logic correctly identifies only the latest action per comment as undoable\n- [x] Verify Terms of Service and Help page contain the required permanence disclosures for deletes/bans
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
Suggestion: Returning 'fail' instead of throwing an error ensures the user stays on the page and receives feedback if the YouTube API call fails.\n\nsuggestion\n\t\t\treturn fail(500, { error: e instanceof Error ? e.message : 'YouTube API failure' });\n
The reason will be displayed to describe this comment to others. Learn more.
⚪ LOW RISK
Nitpick: The createdAt field has a database-level default. Omit it here to let SQLite handle the timestamp consistently using its own internal clock and the schema's defined strftime format.
Restoration sends an unsupported ban parameter with the published moderation status
The YouTube API only supports banAuthor when moderationStatus is rejected; sending banAuthor=false alongside moderationStatus=published can make the restore request fail with a 400. The new restore path must omit that parameter for published restores or use a request-specific API helper.
❌ Normal non-dry-run Undo requests can fail at YouTube.
❌ Held and rejected comments cannot be restored remotely.
⚠️ The local claim is released and the audit row is not written.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/(app)/channels/[id]/log/+page.server.ts
**Line:** 94:94
**Comment:***Api Mismatch: The YouTube API only supports `banAuthor` when `moderationStatus` is `rejected`; sending `banAuthor=false` alongside `moderationStatus=published` can make the restore request fail with a 400. The new restore path must omit that parameter for published restores or use a request-specific API helper.
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
Major
2026-08-02 14:38
Latest suggestions up to commit fa01102
Category
Suggestion
Severity
Generated at (UTC)
Api mismatch
Undo accepts comments based on status without checking that their latest audit action is reversible
The server action authorizes undo solely from the current comment status and never verifies that the latest audit entry is the reversible action being undone. A crafted POST can therefore restore any held or rejected comment whose latest audit action is dry-run, approve, or another non-undoable action, even though the loader does not expose an Undo button for it. Validate the latest audit row and require it to be hold, reject, or ban before claiming the comment.
❌ Non-undoable dry-run actions can be undone directly.
⚠️ Comment status can change without matching UI authorization.
⚠️ Audit rows can describe the wrong action history.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/(app)/channels/[id]/log/+page.server.ts
**Line:** 76:83
**Comment:***Api Mismatch: The server action authorizes undo solely from the current comment status and never verifies that the latest audit entry is the reversible action being undone. A crafted POST can therefore restore any held or rejected comment whose latest audit action is `dry-run`, `approve`, or another non-undoable action, even though the loader does not expose an Undo button for it. Validate the latest audit row and require it to be `hold`, `reject`, or `ban` before claiming the comment.
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
1. Undo can lose audit row✓ Resolved🐞 Bug☼ Reliability
Description
The undo action restores the comment on YouTube and then inserts the restore/dry-run audit row; if
that insert fails, the restore has already happened but will not be recorded. Because the comment
was already flipped to approved, subsequent undo retries will 404 and cannot recreate the missing
audit record.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
Undo first enforces held/rejected eligibility, then updates the comment to approved before
calling YouTube, and finally inserts the audit log row without handling insert failures. If that
last insert throws, the comment remains approved (so future undo attempts fail the held/rejected
check) and the restore action is permanently missing from the audit trail.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`actions.undo` has a failure window after a successful YouTube restore: it updates the comment to `approved` and performs the remote call, then writes the audit row. If the final `db.insert(auditLog)` fails (e.g., transient DB lock/error), the system ends up with a successful external side-effect but no corresponding audit entry, and the undo is no longer retryable because the comment is no longer `held`/`rejected`.
## Issue Context
- Undo is intended to be auditable and reversible; missing the restore audit row undermines this feature and can create compliance/operability gaps.
- The current try/catch only releases the claim on YouTube failures; it does not handle audit insert failures.
## Fix Focus Areas
- src/routes/(app)/channels/[id]/log/+page.server.ts[74-120]
### Suggested change options (pick one)
1) **Introduce a retryable intermediate state** (no migration needed since status is free-text):
- Claim by setting `status: 'restoring'` (or similar) before the remote call.
- After remote success, in a DB transaction: (a) insert the audit row, (b) set `status: 'approved', decidedBy: 'human'`.
- If audit insert fails, keep `status: 'restoring'` so a subsequent retry can re-attempt audit insertion (and/or reconciliation).
2) **Outbox/pending-intent approach**:
- Insert an audit/intention row (e.g., `restore_requested`) in the same transaction as the claim.
- After remote success, update it to `restore` (or add a completion row) and finalize the comment status.
3) At minimum: **retry the audit insert** on transient DB failures and ensure there is a recovery path if the insert ultimately fails (so you don’t end up with “restored but unlogged and non-retryable”).
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
2. Server-only help.test.ts in routes 📘 Rule violation⌂ Architecture
Description
The new help.test.ts and actions.test.ts files import server-only dependencies (Node.js server
APIs and $lib/server/* modules) but are placed under src/routes/ instead of the required
src/lib/server/ directory. This violates the server-only module placement rule and increases the
risk of server/client boundary confusion or accidental client-side bundling/structure drift.
+import { readFileSync } from 'node:fs';+import { fileURLToPath } from 'node:url';+import { dirname, join } from 'node:path';+import { describe, expect, it } from 'vitest';
Relevance
●●● Strong
Clear repo compliance rule: server-only Node/$lib/server tests shouldn’t live under src/routes;
likely enforced.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
PR Compliance ID 2401095 requires server-only modules—including anything importing Node
filesystem/path/url APIs or other server helpers—to live under src/lib/server/. The added
src/routes/(app)/help/help.test.ts imports node:fs, node:url, and node:path while residing
under src/routes/(app)/help/, and src/routes/(app)/channels/[id]/log/actions.test.ts imports
$lib/server/testdb and $lib/server/db/schema while residing under src/routes/(app)/...; both
locations are outside src/lib/server/, demonstrating the violation.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Newly-added test modules that depend on server-only APIs/dependencies are currently located under `src/routes/` instead of `src/lib/server/`, which violates the compliance requirement for server-only module placement.
## Issue Context
PR Compliance ID 2401095 requires any server-only module (including files importing Node.js server APIs like `node:fs`/`node:path`/`node:url` and server helpers such as `$lib/server/*`) to be located under `src/lib/server/`. The following new route-area test files import server-only dependencies while living under `src/routes/(app)/...`, outside the required directory:
- `src/routes/(app)/help/help.test.ts` imports `node:fs`, `node:url`, and `node:path`.
- `src/routes/(app)/channels/[id]/log/actions.test.ts` imports `$lib/server/testdb` and `$lib/server/db/schema`.
## Fix Focus Areas
- src/routes/(app)/help/help.test.ts[19-27]
- src/routes/(app)/channels/[id]/log/actions.test.ts[19-40]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The audit log load path assumes “first row per comment is latest” but orders only by createdAt, so
tied timestamps can cause the wrong entry to be treated as latest and incorrectly show/hide the Undo
button. This is plausible because audit rows are inserted with millisecond timestamps and audit_log
has an auto-increment id that is not used as a tie-breaker.
+ // Newest first: the first entry seen per comment is its latest action, and+ // only that one can be undone. 'hold'/'reject' reverse fully via YouTube;+ // 'ban' restores the comment but the author ban is permanent (no API);+ // everything else ('delete', 'approve', 'queue', 'dry-run', 'restore') is
Relevance
●●● Strong
Deterministic tie-break for “latest per comment” is a low-risk correctness fix; likely welcomed.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
load() orders only by createdAt and then uses a Set to treat the first encountered row per
comment as “latest”. Since audit rows are timestamped via new Date().toISOString() (millisecond
precision) and audit_log has an auto-increment id, ties can occur and should be resolved
deterministically with id ordering.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
The audit log `load()` relies on the first row encountered per `commentId` being the latest action, but the SQL ordering is only `ORDER BY createdAt DESC`. When multiple audit rows share the same `createdAt` (plausible with millisecond precision), the DB may return them in an unspecified order, causing incorrect `undoable` flags.
## Issue Context
- `audit_log` rows have an auto-incrementing `id` that can act as a deterministic tie-breaker.
- The code explicitly derives “latest” from ordering and then sets `undoable` based on that derived latest row.
## Fix Focus Areas
- src/routes/(app)/channels/[id]/log/+page.server.ts[32-55]
### Suggested change
- Change the audit log query ordering to `orderBy(desc(auditLog.createdAt), desc(auditLog.id))`.
- Add/extend a test to cover two rows for the same `commentId` with identical `createdAt` values, asserting the higher `id` is treated as latest (and thus the only one considered for undoability).
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The reason will be displayed to describe this comment to others. Learn more.
1. Server-only help.test.ts in routes 📘 Rule violation⌂ Architecture
The new help.test.ts and actions.test.ts files import server-only dependencies (Node.js server
APIs and $lib/server/* modules) but are placed under src/routes/ instead of the required
src/lib/server/ directory. This violates the server-only module placement rule and increases the
risk of server/client boundary confusion or accidental client-side bundling/structure drift.
Agent Prompt
## Issue description
Newly-added test modules that depend on server-only APIs/dependencies are currently located under `src/routes/` instead of `src/lib/server/`, which violates the compliance requirement for server-only module placement.
## Issue Context
PR Compliance ID 2401095 requires any server-only module (including files importing Node.js server APIs like `node:fs`/`node:path`/`node:url` and server helpers such as `$lib/server/*`) to be located under `src/lib/server/`. The following new route-area test files import server-only dependencies while living under `src/routes/(app)/...`, outside the required directory:
- `src/routes/(app)/help/help.test.ts` imports `node:fs`, `node:url`, and `node:path`.
- `src/routes/(app)/channels/[id]/log/actions.test.ts` imports `$lib/server/testdb` and `$lib/server/db/schema`.
## Fix Focus Areas
- src/routes/(app)/help/help.test.ts[19-27]
- src/routes/(app)/channels/[id]/log/actions.test.ts[19-40]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
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/components/landing/legal/Terms.svelte`:
- Around line 110-111: Update the “Moderation Action” definition in Terms.svelte
section 2 to explicitly include both automatic and manual actions, or introduce
a shared term covering both and use it consistently in section 9.4. Preserve the
existing audit-log statement while removing the ambiguity between the definition
and manual-action logging.
In `@src/lib/landing/legal.test.ts`:
- Around line 291-296: Update the test around the Terms §9 assertion to extract
only section §9.4 before matching. Within that scoped content, assert the
reversible hold/reject statement and retain assertions for the irreversible
deleted-comments and author-bans clauses, ensuring the complete disclosure is
covered.
In `@src/routes/`(app)/channels/[id]/log/+page.server.ts:
- Around line 84-103: Change the restore flow around the comments claim and
YouTube call to record an intermediate pending state or pendingAction before the
external request, rather than setting terminal approved/human immediately.
Promote the comment to approved/human only after setModerationStatus succeeds,
or immediately in dry-run mode; preserve retryability and add the existing
reconciliation mechanism for pending records left by process interruption.
- Around line 48-53: Replace the nested ternary assigned to undoable with a
small named helper or clear if/else chain that preserves the existing latest and
action conditions: return 'full' for latest hold/reject entries, 'comment-only'
for latest ban entries, and null otherwise.
- Around line 32-55: Update the loader query ordering around the rows retrieval
to add auditLog.id as a descending secondary sort key after auditLog.createdAt,
matching the ordering used by the undo action’s prior lookup. Preserve the
existing newest-first ordering and seen-based latest derivation.
In `@src/routes/`(app)/channels/[id]/log/actions.test.ts:
- Around line 24-35: Update the hoisted token mocks and their test assertions so
the channel action verifies decrypt receives the owned channel’s refreshTokenEnc
value ('enc-1') and refreshAccessToken receives the decrypted token
('decrypted-refresh-token'); ensure incorrect or undefined token arguments fail
the test.
🪄 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: 48da94e9-706f-44fa-8da9-3c4475e0151b
📥 Commits
Reviewing files that changed from the base of the PR and between 5d53113 and 14cac31.
<p><strong>9.4</strong> Every Moderation Action, automatic or manual, is recorded in the Service's audit log. Hold and reject actions can be reversed from the audit log, restoring the comment on YouTube. Deleted comments cannot be restored or reversed, and author bans cannot be lifted or reversed — YouTube provides no mechanism to undo either — so both are permanent once executed.</p>
The reason will be displayed to describe this comment to others. Learn more.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Align the Moderation Action definition with manual-action logging.
Section 2 defines Moderation Action as an automated action. This section states that automatic and manual actions are recorded. Update the definition to include manual actions, or define a separate term that covers both. Otherwise, the audit-log disclosure has an ambiguous scope.
Proposed fix
-<p><strong>Moderation Action:</strong> an automated action configured by you ...+<p><strong>Moderation Action:</strong> an automated or manual action configured or performed by you ...
🤖 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/components/landing/legal/Terms.svelte` around lines 110 - 111, Update
the “Moderation Action” definition in Terms.svelte section 2 to explicitly
include both automatic and manual actions, or introduce a shared term covering
both and use it consistently in section 9.4. Preserve the existing audit-log
statement while removing the ambiguity between the definition and manual-action
logging.
…o, safe restore params
- Audit log load breaks createdAt ties with the auto-increment id, so the
wrong entry can never be picked as a comment's latest action (Qodo
#3699381183)
- Undo now claims into a 'restoring' state and commits the audit row and
the approved status in ONE transaction after the remote call: a crash
mid-undo parks the comment retryably instead of losing the audit record
(Qodo #3699381186). The YouTube restore is idempotent, so resume is safe
- setModerationStatus omits banAuthor unless banning — the param is only
valid alongside 'rejected' and defaults to false (CodeAnt suggestion)
codeant-aiBot
added
size:XL
This PR changes 500-999 lines, ignoring generated files
and removed
size:L
This PR changes 100-499 lines, ignoring generated files
labels
Aug 2, 2026
… helper, credential-path assertions
- Terms §9.4 drops the defined-term 'Moderation Action' (§2 scopes it to
automated actions) for the plain 'moderation action, automatic or manual'
- The §9.4 guard test now extracts the section itself and also asserts the
reversible hold/reject statement
- undoable computation is a named helper instead of a nested ternary
(CodeRabbit + SonarQube S3358)
- The undo test asserts the full credential path: decrypt gets the owned
channel's refreshTokenEnc, refreshAccessToken gets the decrypted token
Add full-flow restore coverage for 'held' comments.
Existing tests cover restoring 'rejected' comments (prior actions reject and ban) through the real (non-dry-run) path, but not 'held' comments. hold is documented as a primary fully-reversible action alongside reject. Add an analogous test that seeds a 'held' comment and asserts the same restore/audit behavior.
🧪 Proposed addition
test('undo restores a held comment at YouTube and records the restore',async()=>{awaitseedComment('c1','held','hold');constres=awaitundo('c1');expect(res).toMatchObject({success: expect.stringContaining('estored')});expect(mocks.setModerationStatus).toHaveBeenCalledWith(['c1'],'published',false,'access-token');expect(awaitcommentRow('c1')).toMatchObject({status: 'approved',decidedBy: 'human'});expect(awaittestDb().db.select().from(auditLog).all()).toContainEqual(expect.objectContaining({commentId: 'c1',action: 'restore',reason: 'undo of hold',actor: 'user'}));});
🤖 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/routes/`(app)/channels/[id]/log/actions.test.ts around lines 78 - 101,
Add a full-flow test alongside the existing undo tests that seeds comment c1
with status held and prior action hold, invokes undo('c1'), and verifies the
restore success response, published YouTube moderation call, approved
human-decided comment row, and restore audit entry with reason undo of hold and
actor user.
84-136: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Concurrent resumers of a 'restoring' comment can each write a duplicate restore audit row.
The atomic claim at Line 91-95 only protects the fresh-claim path (if (!resuming)). Once a comment's status is 'restoring' — including while a first request is still mid-flight, not just after a crash — any concurrent duplicate undo submission also takes the resuming branch, skips the claim, and reaches the final transaction at Line 126-136 unguarded. Each concurrent resumer independently inserts a restore audit row and sets the comment to approved/human. This contradicts the design intent of atomic claiming preventing "duplicate concurrent undo operations," and pollutes the audit log with duplicate entries for a single logical undo.
Guard the final transaction with the same conditional-update pattern already used for the claim: update only WHERE status = 'restoring', and only insert the audit row if the update actually affected a row.
🐛 Proposed fix
await db.transaction(async (tx) => {
- await tx.insert(auditLog).values({- channelId: params.id,- commentId,- action: dryRun ? 'dry-run' : 'restore',- reason: `undo of ${prior?.action ?? 'moderation action'}`,- actor: 'user',- createdAt: new Date().toISOString()- });- await tx.update(comments).set({ status: 'approved', decidedBy: 'human' }).where(eq(comments.id, commentId));+ // Single-winner guard: only the request that actually flips+ // 'restoring' -> 'approved' writes the audit row. A concurrent+ // resumer of the same comment (double-click, retry) finds 0+ // rows here and no-ops instead of duplicating the audit entry.+ const updated = await tx+ .update(comments)+ .set({ status: 'approved', decidedBy: 'human' })+ .where(and(eq(comments.id, commentId), eq(comments.status, 'restoring')))+ .returning({ id: comments.id });+ if (updated.length === 0) return;+ await tx.insert(auditLog).values({+ channelId: params.id,+ commentId,+ action: dryRun ? 'dry-run' : 'restore',+ reason: `undo of ${prior?.action ?? 'moderation action'}`,+ actor: 'user',+ createdAt: new Date().toISOString()+ });
});
🤖 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/routes/`(app)/channels/[id]/log/+page.server.ts around lines 84 - 136,
Guard the final transaction in the undo flow around the existing comments update
and auditLog insert so only one restoring request can finalize. Conditionally
update the comment from status 'restoring' to 'approved' and set decidedBy to
'human', inspect the affected-row result, and insert the restore audit row only
when that update succeeds; treat zero affected rows as an already-finalized
concurrent request without writing another audit entry.
🤖 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.
Outside diff comments:
In `@src/routes/`(app)/channels/[id]/log/+page.server.ts:
- Around line 84-136: Guard the final transaction in the undo flow around the
existing comments update and auditLog insert so only one restoring request can
finalize. Conditionally update the comment from status 'restoring' to 'approved'
and set decidedBy to 'human', inspect the affected-row result, and insert the
restore audit row only when that update succeeds; treat zero affected rows as an
already-finalized concurrent request without writing another audit entry.
In `@src/routes/`(app)/channels/[id]/log/actions.test.ts:
- Around line 78-101: Add a full-flow test alongside the existing undo tests
that seeds comment c1 with status held and prior action hold, invokes
undo('c1'), and verifies the restore success response, published YouTube
moderation call, approved human-decided comment row, and restore audit entry
with reason undo of hold and actor user.
ℹ️ Review info⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 685413da-e3d3-42c9-ac52-fc47f8c9bd39
📥 Commits
Reviewing files that changed from the base of the PR and between 14cac31 and fa01102.
The test checks only setModerationStatus. It would pass if the handler still called decrypt or refreshAccessToken. Add not.toHaveBeenCalled() assertions for both mocks.
As per coding guidelines, tests must fail when the real logic is wrong.
🤖 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/routes/`(app)/channels/[id]/log/actions.test.ts around lines 129 - 140,
Extend the dry-run test around undo('c1') to assert that both credential-related
mocks, decrypt and refreshAccessToken, are not called, alongside the existing
setModerationStatus assertion. Ensure the test verifies that dry-run execution
skips all YouTube and credential calls.
UC2 is not inserted before the request, so the test proves only that a missing channel returns 404. An authorization regression that permits access to an existing channel owned by another user could still pass.
Insert UC2 with a different userId and a rejected comment, then submit the undo request for that channel and assert 404, no YouTube call, and no state change.
As per coding guidelines, another user's channel must return 404 without leaking existence, and tests must fail when the real logic is wrong.
🤖 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/routes/`(app)/channels/[id]/log/actions.test.ts around lines 175 - 180,
Update the test “undo on another user’s channel 404s without leaking existence”
to seed an existing UC2 channel owned by a different user, including its
rejected comment, before calling undo. Assert the request returns 404, the
YouTube call is not made, and the comment remains rejected, ensuring the test
detects authorization regressions rather than only missing-channel behavior.
89-98: 🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Keep resumed restore claims exclusive.
When a second request reads status === 'restoring', it skips the conditional claim and can run concurrently with the first request. Both requests can call YouTube and insert restore audit rows. If the first request then fails, Lines 108-112 can restore the old status after the second request has committed approved.
Use a durable claim owner or lease for resumed attempts. Make both the release and final commit conditional on that claim. Add a concurrent-request test.
Also applies to: 108-112, 127-137
🤖 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/routes/`(app)/channels/[id]/log/+page.server.ts around lines 89 - 98, The
restore flow around the conditional update and the error-release/final-commit
paths must keep resumed attempts exclusive. Add a durable claim owner or lease
that is acquired for both new and resumed restores, and make the release and
final status/audit commit conditional on that same claim so an earlier failed
request cannot overwrite a later successful one. Add a concurrent-request test
covering two restores when the comment is already in restoring status.
82-84: 🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Validate the latest audit action before claiming the comment.
The loader derives undoability from the latest audit row, but the action validates only comments.status. The prior query then filters to hold, reject, and ban, so it can select an older reversible row when a newer delete, approve, queue, dry-run, or restore row exists.
Select the latest audit row before the YouTube call. Require its action to be hold, reject, or ban, and use that exact row for the restore reason.
Also applies to: 116-123
🤖 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/routes/`(app)/channels/[id]/log/+page.server.ts around lines 82 - 84,
Update the claim action around the comment status validation to fetch and
validate the latest audit row before making the YouTube call. Require that row’s
action to be hold, reject, or ban, reject comments whose latest action is
delete, approve, queue, dry-run, or restore, and reuse the validated row for the
restore reason instead of selecting an older reversible audit entry via prior.
🤖 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/landing/legal.test.ts`:
- Around line 289-297: Add an assertion in the §9.4 test around the existing s94
checks to require disclosure of both automatic and manual moderation actions,
using the exact wording or established terminology from the terms content. Keep
the existing reversibility assertions unchanged and ensure the test fails when
either scope is omitted.
---
Outside diff comments:
In `@src/routes/`(app)/channels/[id]/log/+page.server.ts:
- Around line 89-98: The restore flow around the conditional update and the
error-release/final-commit paths must keep resumed attempts exclusive. Add a
durable claim owner or lease that is acquired for both new and resumed restores,
and make the release and final status/audit commit conditional on that same
claim so an earlier failed request cannot overwrite a later successful one. Add
a concurrent-request test covering two restores when the comment is already in
restoring status.
- Around line 82-84: Update the claim action around the comment status
validation to fetch and validate the latest audit row before making the YouTube
call. Require that row’s action to be hold, reject, or ban, reject comments
whose latest action is delete, approve, queue, dry-run, or restore, and reuse
the validated row for the restore reason instead of selecting an older
reversible audit entry via prior.
In `@src/routes/`(app)/channels/[id]/log/actions.test.ts:
- Around line 129-140: Extend the dry-run test around undo('c1') to assert that
both credential-related mocks, decrypt and refreshAccessToken, are not called,
alongside the existing setModerationStatus assertion. Ensure the test verifies
that dry-run execution skips all YouTube and credential calls.
- Around line 175-180: Update the test “undo on another user’s channel 404s
without leaking existence” to seed an existing UC2 channel owned by a different
user, including its rejected comment, before calling undo. Assert the request
returns 404, the YouTube call is not made, and the comment remains rejected,
ensuring the test detects authorization regressions rather than only
missing-channel behavior.
🪄 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: 283fcaee-7f1a-48a7-974c-3aabc20f21a3
📥 Commits
Reviewing files that changed from the base of the PR and between fa01102 and a621fcf.
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Assert the automatic/manual scope in §9.4.
The test checks only audit log, so it can pass if the disclosure omits manual actions. Add an assertion for the complete scope, for example:
Proposed assertion
expect(s94).toMatch(/audit log/i);
+ expect(s94).toMatch(/every moderation action, automatic or manual, is recorded/i);
As per coding guidelines, tests must fail when the real logic is wrong.
📝 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.
Suggested change
// The undo feature's honesty guard: §9.4 must disclose exactly which
// moderation actions cannot be reversed (YouTube offers no API for them).
it('Terms §9.4 discloses which moderation actions are reversible and which are not',()=>{
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/landing/legal.test.ts` around lines 289 - 297, Add an assertion in
the §9.4 test around the existing s94 checks to require disclosure of both
automatic and manual moderation actions, using the exact wording or established
terminology from the terms content. Keep the existing reversibility assertions
unchanged and ensure the test fails when either scope is omitted.
…ng change
PR #46 already shipped 1.3 (Terms §9.4 reversible actions); the pricing
overhaul is a separate material change, so it gets its own version
(1.4, effective 2 August 2026) instead of sharing 1.3.
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:L
![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}
User description
Behavior
Logging was already complete (
audit_logcovers pipeline, queue, and dry-run actions); this PR adds reversibility:hold/rejectrestore the comment at YouTube viasetModerationStatus(..., 'published');banoffers "Undo comment" (the comment is restored — YouTube has no API to lift an author ban);deleteoffers nothing (permanent).DRY_RUN=truerecords adry-runaudit row and makes no YouTube call (I8). Every undo writes arestoreaudit row naming the original action (derived server-side).approved/human.Disclosure (per review feedback):
LEGAL_VERSIONbumped to1.3, so existing users re-accept via the established/consentflow on next login.Verification
svelte-checkclean, production build green.publishedAPI params, Terms §9.4 disclosure guard, Help tab presence + copy.Notes
CodeAnt-AI Description
Add reversible moderation actions through the audit log
What Changed
Impact
✅ Restore held or rejected comments from the audit log✅ Retry interrupted restores without losing the action✅ Clearer limits for bans and deletions💡 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:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
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:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
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.