When dryRun is true, deleteAccount logs the preview and carries on to database.deleteAccount, because the dry-run branch never returns.
Impact
A dry run deletes the account it was meant to preview, and the audit log records the deletion as real.
Recommended solution
Return straight after logging the preview, or move the deletion into an explicit else branch, and add a test that a dry run leaves the account in place.
Why this was flagged
Check findings at these lines
No check finding in this report is at these lines. This finding comes from the AI review reading the source below.
Source the review cited
src/accounts/delete-account.ts:14-19
Independent review
Kept with high confidence. The dry-run branch logs the preview and falls through to the delete call.
Limits
The AI review reads selected excerpts of the repository, not every file. This finding is a reviewed judgement about the lines above, not a deterministic match.
This finding has no identity that carries across scans, so it can’t be suppressed on its own.
Refund amount isn’t checked
The refund amount crosses three files unchecked
The refund amount crosses three files unchecked. 3 reviewed components and 2 reviewed relationships. Route reads the amount from the request body (src/routes/refunds.ts:14–17) leads to refundOrder passes it on without a limit (src/orders/refund-order.ts:9–14): Number(req.body.amount) (src/routes/refunds.ts:15). refundOrder passes it on without a limit (src/orders/refund-order.ts:9–14) leads to Payments client sends it to the gateway (src/payments/client.ts:21–23): Same amount, never compared with the order (src/orders/refund-order.ts:11).
refundOrder passes it on without a limitPayments client sends it to the gateway
Same amount, never compared with the orderRelationship sourcesrc/orders/refund-order.ts:11
Problem
The refund route reads amount from the request body and refundOrder passes it to payments.refund without comparing it with what the order was paid. The payments client sends it to the gateway as it is.
Impact
A staff request can refund more than the order's total, and a missing amount reaches the gateway as NaN.
Recommended solution
Check the amount in refundOrder: reject anything that isn't a positive number or that exceeds the order's total less earlier refunds, and add a test for each case.
Why this was flagged
Check findings at these lines
No check finding in this report is at these lines. This finding comes from the AI review reading the source below.
Source the review cited
src/orders/refund-order.ts:9-14
src/routes/refunds.ts:14-17
src/payments/client.ts:21-23
Independent review
Kept with high confidence. The amount from the request body reaches the payment gateway with no bound in any of the three files.
Limits
The AI review reads selected excerpts of the repository, not every file. This finding is a reviewed judgement about the lines above, not a deterministic match.
This finding has no identity that carries across scans, so it can’t be suppressed on its own.
Findings
Every confirmed finding, grouped by the check or AI review that raised it. Open a group to read its findings here.
Possible credentials
The secret scan matched these lines by pattern. They are not reviewed by AI. SlopCop doesn’t read or show the value.
If one is a real credential, rotate it and remove it from the code.
src/payments/client.ts:4Matches API key · high confidence
Design review
Design recommendations from AI review, with the code and relationships behind each suggestion. 1 more problem it found was confirmed as a defect and is under Findings.
Full design review.
Invoice export checks session expiry with its own rule
Two places decide when a session expires
Two places decide when a session expires. 3 reviewed components and 2 reviewed relationships. Export route reads the session cookie (src/routes/billing.ts:22–25) leads to Export handler checks idle time itself (src/billing/export-invoices.ts:27–29): Passes a raw session id (src/routes/billing.ts:23). Export handler checks idle time itself (src/billing/export-invoices.ts:27–29) leads to Auth defines expiry and revocation (src/auth/sessions.ts:13–18): Uses 30 minutes and skips revocation (src/billing/export-invoices.ts:29).
Export route reads the session cookieSourcesrc/routes/billing.ts:22–25
Export handler checks idle time itselfSourcesrc/billing/export-invoices.ts:27–29
Auth defines expiry and revocationSourcesrc/auth/sessions.ts:13–18
Reviewed relationships
Export route reads the session cookieExport handler checks idle time itself
Passes a raw session idRelationship sourcesrc/routes/billing.ts:23
Export handler checks idle time itselfAuth defines expiry and revocation
Uses 30 minutes and skips revocationRelationship sourcesrc/billing/export-invoices.ts:29
Problem
The export route passes the raw session id to the export handler, which reads the session row and applies its own 30-minute idle limit with no revocation check, instead of calling isSessionActive.
Impact
A revoked session, or one idle for 20 to 30 minutes, can still export invoices after the rest of the service has signed it out.
Recommended solution
Check the session with isSessionActive before exporting, and keep the expiry rule, timeout included, in the auth module.
Why this was flagged
Check findings at these lines
No check finding in this report is at these lines. This finding comes from the AI review reading the source below.
Source the review cited
src/billing/export-invoices.ts:27-29
src/routes/billing.ts:22-25
src/auth/sessions.ts:13-18
Independent review
Kept with high confidence. The export handler re-implements idle expiry and skips the revocation check.
Limits
The AI review reads selected excerpts of the repository, not every file. This finding is a reviewed judgement about the lines above, not a deterministic match.
This finding has no identity that carries across scans, so it can’t be suppressed on its own.
See what turns up in your own code.
Create an account, pick a repository, and SlopCop starts indexing it.
