Skip to content

fix: replace in-memory receipt store with persistent database access - #957

Open
Calebstack wants to merge 32 commits into
Pulsefy:mainfrom
Calebstack:fix/issue-804-be-105-replace-in-memory-receipt-store-with
Open

Calebstack wants to merge 32 commits into
Pulsefy:mainfrom
Calebstack:fix/issue-804-be-105-replace-in-memory-receipt-store-with

Conversation

@Calebstack

Copy link
Copy Markdown

Overview

This PR replaces the in-memory receipt store with a persistent database-backed repository. Receipt reads and writes now go through the database, so receipts survive process restarts and stay consistent across multiple instances. The existing receipt normalization and hash behavior are preserved, with the service delegating to a new repository layer.

Related Issue

Closes BE-105

Changes

🗄️ Persistent Receipt Repository

  • [ADD] app/backend/src/receipts/receipts.repository.ts

    • Implements database-backed receipt read/write operations using the existing Supabase/database client.
    • Handles not-found cases by returning null/empty results instead of throwing for missing rows.
    • Supports upsert behavior driven by the existing receipt ID/hash.
  • [ADD] app/backend/src/receipts/migrations/001_create_receipts_table.sql

    • Creates the receipts table with columns for the normalized receipt payload, ID/hash, timestamps, and metadata required by the service.
  • [ADD] app/backend/src/receipts/receipts.types.ts

    • Exports shared persistence types: stored receipt DTO, receipt record, and repository interface.
  • [MODIFY] app/backend/src/receipts/receipts.module.ts

    • Wires ReceiptsRepository into the module and registers it for dependency injection.
  • [MODIFY] app/backend/src/receipts/receipts.service.ts

    • Removes the TODO and swaps the in-memory map for the repository-backed store.
    • Keeps receipt normalization and hash computation unchanged before repository calls.

🧪 Test Coverage

  • [ADD] app/backend/src/receipts/receipts.repository.unit.spec.ts

    • Covers persistence: writes then reads.
    • Covers not-found handling.
    • Covers multi-instance consistency assumptions: any repository instance reading the same DB returns the same receipt.
  • [MODIFY] app/backend/src/receipts/receipts.service.unit.spec.ts

    • Updates service tests to assert repository delegation while preserving normalization/hash behavior checks.

Verification Results

npm test -- app/backend/src/receipts/receipts.service.unit.spec.ts app/backend/src/receipts/receipts.repository.unit.spec.ts
✅ All service + repository tests pass

Live acceptance check:
✅ Receipt survives simulated process restart
✅ Missing receipt handled as not-found
✅ Multi-instance consistency simulation passes
Acceptance Criteria Status
Receipt reads and writes go through the database rather than in-process state ✅ Repository-backed database reads/writes replace the in-memory store
Receipts survive a process restart and are consistent across multiple instances ✅ Verified via simulated restart and multi-instance consistency checks
Existing receipt normalization and hash behavior is unchanged ✅ Service preserves existing normalization/hash logic and repository delegation keeps it intact
Tests cover persistence, not-found handling, and multi-instance consistency assumptions ✅ Persistence, not-found, and multi-instance repository/service tests added

Closes #804

@drips-wave

drips-wave Bot commented Aug 27, 2026

Copy link
Copy Markdown

@Calebstack Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

@Cedarich

Copy link
Copy Markdown
Contributor

@Calebstack

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

BE-105: Replace In-Memory Receipt Store with Persistent Database Access

2 participants