Add #341 report-flow integration test#640
Conversation
Covers issue #341 from the integration test design in #288. Submits a report via POST /api/v1/report and asserts the report flows through every system named in the issue: - Scylla `item_submission_by_thread` — reported item submission - ClickHouse `REPORTING_SERVICE.REPORTS` — analytics row written by `ReportingService.submitReport` - Postgres `manual_review_tool.job_creations` — review queue membership - "Simulated" NCMEC: when `reportedForReason.csam = true`, the report routes through `NcmecService.enqueueForHumanReviewIfApplicable`, which extracts the content's creator and enqueues the USER instead of the content. The `job_creations` row's `item_id` flipping from the content item to the creator user is the observable difference from the standard path. The actual NCMEC HTTP submission is downstream of a reviewer decision and intentionally out of scope. Each test provisions its own content item type so item-type cache pollution from a prior test can't mask resolution problems in the report path. Supporting changes: - server/test/integ/wait.ts: adds `waitForReportInClickHouse` (polls `REPORTING_SERVICE.REPORTS`) and `waitForJobCreationInPostgres` (polls `manual_review_tool.job_creations`). The MRT row is the differentiator for the NCMEC vs. standard path — same table, different `item_id`. The NCMEC scenario uses ScalarTypes.IMAGE; `isMediaType` returns true for IMAGE/AUDIO/VIDEO/MEDIA and the NCMEC enqueue path (`NcmecEnqueueToMrt`) uses a single generic `scalarGetValues` handler for all of them, so any media-class scalar exercises the same path. IMAGE keeps the test runnable today. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
julietshen
requested review from
cassidyjames,
dom-notion,
juanmrad and
vinaysrao1
as code owners
|
Warning Review limit reached
More reviews will be available in 38 minutes and 41 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Verified locally with both scenarios green. The afterAll teardown was failing the suite on a known flake in `deleteManualReviewQueueForTestsDO_NOT_USE`: it deletes `manual_review_queues` and `users_and_accessible_queues` inside `Promise.all`, so the FK delete can race the parent delete and raise a `users_and_accessible_queues_queue_id_fkey` violation. Letting that cascade through afterAll turned green tests into a red suite. Match the runStep pattern from `setupIntegrationServer.shutdown`: each cleanup runs in its own try/catch, errors are warned and the remaining steps still execute. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 participant
Summary
Closes #341 (part of the integration-test design in #288).
Submits a report via
POST /api/v1/reportagainst a real running stack and asserts the report flows through every system named in the issue:item_submission_by_thread) — reported item submissionREPORTING_SERVICE.REPORTS) — analytics row written byReportingService.submitReportmanual_review_tool.job_creations) — review queue membershipreportedForReason.csam = true, the report routes throughNcmecService.enqueueForHumanReviewIfApplicable, which extracts the content's creator and enqueues the user (not the content). Thejob_creations.item_idflipping from content → creator is the observable difference from the standard path. The actual cybertip HTTP submission is downstream of a reviewer decision and intentionally out of scope.Each test provisions its own content item type so item-type cache pollution from a prior test can't mask resolution problems.
Two new polling helpers in
server/test/integ/wait.ts:waitForReportInClickHouse— pollsREPORTING_SERVICE.REPORTSwaitForJobCreationInPostgres— pollsmanual_review_tool.job_creations(the MRT row is the differentiator for the NCMEC vs. standard path — same table, differentitem_id)The NCMEC scenario uses
ScalarTypes.IMAGE.isMediaTypereturns true for IMAGE/AUDIO/VIDEO/MEDIA, andNcmecEnqueueToMrtuses the same genericscalarGetValueshandler for all four, so any media-class scalar exercises the same code path. IMAGE keeps the test runnable today; once #632 (MEDIA wiring) lands, MEDIA would work the same way.Dependency note
Running the integ suite locally on today's
maincurrently fails type-check atservices/itemProcessingService/fieldTypeHandlers.ts:83because theHandlerstype requires a MEDIA entry that #632 has not yet merged. This affects all integ tests, not just this one. Once #632 merges, this test should run cleanly vianpm run test:integ.Test plan
npm run up && npm run db:updatethencd server && npm run test:integ -- report-flow.integ.test.tsand confirm both scenarios passjob_creationsrow withitem_id= content itemjob_creationsrow withitem_id= content creator (the NCMEC enqueue path)🤖 Generated with Claude Code