The service has no database — anchors, liquidity and settlements live in in-memory Maps and are destroyed on every restart #220

Activity

1. Jagadeeshftw

   added

   enhancementNew feature or improvementNew feature or improvement

   Maybe RewardedGrantFox: potentially rewarded contributionGrantFox: potentially rewarded contribution

   GrantFox OSSGrantFox open-source programGrantFox open-source program

   priority:highHigh difficulty / architectural or cross-cuttingHigh difficulty / architectural or cross-cutting

   Third CampaignGrantFox third campaign issueGrantFox third campaign issue

   on Aug 20, 2026
2. Baskarayelu commented on Aug 27, 2026

   

   Baskarayelu

   on Aug 27, 2026

   Contributor

   More actions

   I’d love to be assigned this issue and contribute across the relevant areas, whether it involves smart contracts, UI development, backend logic, design implementation, or overall system integration. I’m comfortable working across the full stack and can adapt to the project’s technical requirements to ensure a smooth and consistent contribution.
3. Jagadeeshftw

   assigned

   Baskarayelu

   on Aug 27, 2026
4. grantfox-oss commented on Aug 27, 2026

   

   grantfox-ossBot

   on Aug 27, 2026 – with GrantFox OSS

   More actions

   🦊 GrantFox — @Baskarayelu has been assigned to this issue as part of the Third Campaign campaign!

   Next steps:

   1. Open a Pull Request referencing this issue (e.g., Closes #220)
   2. Your PR will be reviewed by the AnchorNet-Org maintainers

   Good luck! Track your progress on GrantFox.
5. Baskarayelu commented on Aug 30, 2026

   

   Baskarayelu

   on Aug 30, 2026

   Contributor

   More actions

   Proposed persistence architecture (before implementation)

   I propose PostgreSQL as the durable store, using the official pg driver and SQL migrations managed by node-pg-migrate. PostgreSQL fits this domain better than SQLite (single-writer/file-oriented and awkward for horizontally scaled deploys), Redis (not the system of record and weak for relational audit queries), or a document store (the anchor/asset/settlement relationships and financial constraints are naturally relational). It also gives us row locks, transactional durability, and operational tooling for backups, replicas, and managed deployments.

   Schema

   The first migration would create:

   anchors (
     id text primary key,
     name text not null,
     registered_at timestamptz not null,
     active boolean not null
   )
   
   liquidity_entries (
     anchor text not null references anchors(id),
     asset text not null,
     amount numeric(78,0) not null check (amount >= 0),
     updated_at timestamptz not null,
     primary key (anchor, asset)
   )
   
   settlements (
     id bigint generated always as identity primary key,
     anchor text not null references anchors(id),
     asset text not null,
     amount numeric(78,0) not null check (amount > 0),
     fee numeric(78,0) not null check (fee >= 0),
     status text not null check (status in ('pending','executed','cancelled')),
     created_at timestamptz not null,
     cancel_reason text
   )

   Indexes would mirror the existing repository access paths: settlements(anchor, id), settlements(asset, id), settlements(status, id), and liquidity_entries(asset, anchor). The primary keys cover anchor lookup and (anchor, asset) liquidity lookup. Settlement IDs remain monotonic so current list ordering is deterministic.

   numeric(78,0) preserves the integer range represented by the current bigint values without converting financial amounts through JavaScript numbers. The driver layer will map these columns to strings/bigints at the repository boundary.

   Interfaces and sequencing

   I would migrate one repository at a time behind the current repository interfaces, beginning with anchors, then liquidity, then settlements. The service classes and public response shapes should remain unchanged. I expect the existing method signatures to remain unchanged; if the concurrency boundary requires an additional internal repository method, it will be kept private to the repository composition rather than pushed into the service API. Each step can therefore be reviewed and tested independently, while the final PR can include all three migrations if the maintainer prefers one atomic rollout.

   For the double-spend case, settlement creation must execute as one database transaction: lock the relevant (asset, anchor) liquidity rows with SELECT ... FOR UPDATE, calculate the currently reserved amount under the same transaction, reject if the remaining available amount is insufficient, and insert the pending settlement before commit. A second transaction waits for the row lock and then observes the reduced availability, so both requests cannot succeed against the same balance. The concurrency test will issue two opens against one funded pool and assert exactly one succeeds.

   Migration and configuration

   • CI runs npm run migrate up against a disposable PostgreSQL service before integration tests, then rolls back/destroys that database after the job.
   • Development runs the same command against DATABASE_URL, with a documented local Docker Compose PostgreSQL option.
   • Deploy runs migrations as a release/pre-deploy step before application instances start; migrations are forward-only and acquire PostgreSQL advisory locking so two replicas cannot apply them concurrently.
   • DATABASE_URL is required for the database-backed runtime. loadConfig will validate it and the startup path will open a connection and fail fast with an actionable message if the database is unreachable.
   • The in-memory repositories remain the default test doubles for unit tests. Database integration tests use the disposable CI PostgreSQL service and cover migrations, mapping, rollback, and concurrent settlement creation. This preserves fast tests without hiding the important transaction behavior.

   I will wait for maintainer agreement on this schema, tooling, sequencing, and test strategy before writing implementation code, as requested by this issue.
6. Jagadeeshftw

   closed this as completedin #239on Aug 30, 2026