CodeRabbit Generated Unit Tests: Add unit tests

[coderabbitai]

Unit test generation was requested by @chitcommit.

• feat: complete Phase 2 Hono route migration #41 (comment)

The following files were modified:

• server/__tests__/bookkeeping-workflows.test.ts
• server/__tests__/routes-charges.test.ts
• server/__tests__/routes-wave-oauth.test.ts
• server/__tests__/wave-bookkeeping.test.ts

[coderabbitai]

Important

Review skipped

This PR was authored by the user configured for CodeRabbit reviews. CodeRabbit does not review PRs authored by this user. It's recommended to use a dedicated user account to post CodeRabbit review feedback.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 205478ab-fe82-4fbc-a69f-e4a6e176d707

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	chittyfinance	1487bdb	Apr 26 2026, 01:41 AM

[github-actions]

@coderabbitai review

Please evaluate:

• Security implications
• Credential exposure risk
• Dependency supply chain concerns
• Breaking API changes

[coderabbitai]

🧩 Analysis chain

I'll inspect the test files and dependencies before triggering the full review.

---

🏁 Script executed:

#!/bin/bash
echo "=== bookkeeping-workflows.test.ts ==="
cat server/__tests__/bookkeeping-workflows.test.ts

echo ""
echo "=== routes-charges.test.ts ==="
cat server/__tests__/routes-charges.test.ts

echo ""
echo "=== routes-wave-oauth.test.ts ==="
cat server/__tests__/routes-wave-oauth.test.ts

echo ""
echo "=== wave-bookkeeping.test.ts ==="
cat server/__tests__/wave-bookkeeping.test.ts

echo ""
echo "=== package.json (server or root) ==="
fd -i 'package.json' --max-depth 2 --exec cat {}

echo ""
echo "=== Any hardcoded secrets/tokens in test files? ==="
rg -nP '(api[_-]?key|secret|password|token|bearer|client_id|client_secret)\s*[:=]\s*["\x27][^"\x27]{6,}' server/__tests__/ -i

echo ""
echo "=== Any real URLs (non-localhost) in test files? ==="
rg -nP 'https?://(?!localhost|127\.0\.0\.1|example\.com)' server/__tests__/

Length of output: 68144

---

Let me verify the major version numbers for key dependencies before finalizing the review.

@github-actions[bot] Here is the security-focused evaluation of PR #109.

---

Security Review: PR #109 — Unit Tests

⚠️ Note: I'm replying to the latest comment without access to the earlier conversation thread.

---

1. 🔒 Security Implications

Overall assessment: ✅ Low risk

• All four test files correctly mock every external dependency (storage, WaveAPIClient, chittychronicle-logging, reconciliation, ml-categorization, etc.) using vi.mock() — no live network calls can occur during test execution.
• ChittyChronicle audit logging is properly mocked in both bookkeeping-workflows.test.ts and wave-bookkeeping.test.ts, consistent with the requirement to log financial mutations for audit trails.
• Auth middleware is intentionally bypassed in the test app builders (e.g., buildApp, buildAuthorizeApp), which is the correct pattern for unit tests. However, there are no negative-path authentication tests (e.g., "unauthenticated request → 401"). Consider adding these to the integration test layer.
• The routes-wave-oauth.test.ts callback tests verify that Wave error reasons are preserved verbatim in the redirect URL (e.g., user_denied_access). It's worth confirming that the production implementation sanitizes/allowlists these values to prevent open-redirect or error-message injection abuse.

---

2. 🗝️ Credential Exposure Risk

Assessment: ✅ No real credentials present

All credential-like values in these test files are clearly synthetic test fixtures:

File	Value	Risk
routes-charges.test.ts	CHITTY_AUTH_SERVICE_TOKEN: 'svc-token'	None — placeholder
routes-wave-oauth.test.ts	WAVE_CLIENT_SECRET: 'wave-client-secret'	None — placeholder
routes-wave-oauth.test.ts	OAUTH_STATE_SECRET: 'super-secret-32-chars-minimum-ok'	None — synthetic value crafted to meet length requirements
routes-wave-oauth.test.ts	DATABASE_URL: 'postgres://fake/db'	None — invalid DSN
wave-bookkeeping.test.ts	clientSecret: 'client-secret'	None — placeholder
routes-charges.test.ts mock	credentials: { secret_key: 'sk_test_xxx' }	None — resembles Stripe test key format, but sk_test_xxx is not a valid Stripe token

None of these values are real credentials. No process.env reads of actual secrets occur in the four PR files, and all external clients are mocked before any module under test can use them.

---

3. 📦 Dependency Supply Chain

Assessment: ⚠️ One version mismatch to watch

The latest published version of vitest is 4.1.4, so vitest: ^4.0.18 in package.json is legitimate and currently resolves near this version. The package shows 0 known vulnerabilities as of April 2026.

However, there is a potential compatibility tension:

• Vitest 4.1 adds support for the new Vite 8 version.
• The project currently pins vite: ^7.2.7, while the latest Vite version is 8.0.9.
• Because vitest: ^4.0.18 can resolve to 4.1.x, and Vitest now uses the installed Vite version instead of downloading a separate dependency, if possible — making type inconsistencies in the config obsolete — there may be breakage if the semver range bumps vitest to 4.1.x while Vite remains at 7.x.

Recommendation: Either pin vitest to ~4.0.x (patch-range only) until Vite is upgraded to 8, or upgrade vite to ^8.0.0 at the same time. Vite 8 uses Rolldown and Oxc-based tools instead of esbuild and Rollup, so that upgrade has its own migration checklist.

The @chittyos/schema: file:../../CHITTYFOUNDATION/chittyschema local monorepo dependency is outside the repository boundary and cannot be audited from this PR, but it is not a supply chain risk in the traditional npm sense.

The pnpm.overrides section reflects active security patching (axios >=1.13.5, rollup >=4.59.0, express-rate-limit >=8.2.2), which is a positive hygiene signal.

---

4. 🔁 Breaking API Changes

Assessment: ✅ No breaking changes introduced; implicit contract encoding is intentional

The tests do not modify any production APIs. They do, however, encode specific business logic constants as implicit contracts that will cause test failures if changed — which is the desired behavior for a test suite:

• runQuarterlyTaxPrep — estimatedTax asserted at 25% of net income
• runYearEndClose — estimatedTax asserted at 25% of (taxableIncome - deductions)
• WorkflowScheduler — nextRun asserted within a 23–25 hour window after execution

These are regression guards, not risks. If the tax rate or scheduling interval changes in production code, these tests will correctly catch the drift.

---

Summary

Category	Status	Action
Security implications	✅ Clean	Consider adding unauthenticated-request negative tests at the integration layer
Credential exposure	✅ Clean	All values are clearly synthetic fixtures
Supply chain	⚠️ Watch	Pin vitest to ~4.0.x or upgrade vite to ^8.0.0 before vitest auto-bumps to 4.1.x
Breaking API changes	✅ Clean	No production API surface modified; business logic constants are intentional regression guards

---

🧠 Learnings used

Learnt from: CR
Repo: chittyapps/chittyfinance PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-24T10:51:10.953Z
Learning: Applies to server/routes/**/*.ts : For Mercury Bank integration, use ChittyConnect backend at CHITTYCONNECT_API_BASE with service authentication. Handle multi-account selection and static egress IP for bank compliance.

---

Learnt from: CR
Repo: chittyapps/chittyfinance PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-24T10:51:10.953Z
Learning: Applies to server/routes/**/*.ts : Log to ChittyChronicle for audit trails of financial mutations (classifications, COA changes, transaction reclassifications). Include actor attribution and timestamp.

✅ Actions performed

This PR was authored by the user configured for CodeRabbit reviews. CodeRabbit does not review PRs authored by this user. It's recommended to use a dedicated user account to post CodeRabbit review feedback.