Add SQLite persistence to randomness service

[GabrielMartinezRodriguez]

Linked Issues

• closes https://linear.app/happychain/issue/HAPPY-148/randomness-service-have-a-database-to-store-the-commitments

Description

Adds SQLite persistence to the randomness service for storing commitments. This ensures commitments are not lost on service restart and enables proper pruning of old commitments.

Key changes:

• Added SQLite database integration with Kysely ORM
• Created migration for commitments table
• Implemented commitment persistence and pruning logic
• Modified service startup to load existing commitments from database

Toggle Checklist

Checklist

Basics

• B1. I have applied the proper label & proper branch name (e.g. norswap/build-system-caching).
• B2. This PR is not so big that it should be split & addresses only one concern.
• B3. The PR targets the lowest branch it can (ideally master).

Correctness

• C1. Builds and passes tests.
• C2. The code is properly parameterized & compatible with different environments.
• C3. I have manually tested my changes & connected features.

Tested with:

• Local development environment

Scenarios tested:

• Service startup with empty database

• Service startup with existing commitments

• Commitment persistence across restarts

• Automatic pruning of old commitments

• C4. I have performed a thorough self-review of my code.

Architecture & Documentation

• D1. I made it easy to reason locally about the code.
• D2. All public-facing APIs & meaningful internal APIs are properly documented.
• D3. If appropriate, the general architecture is documented.

[GabrielMartinezRodriguez]

• Deploy randomness service #416 : 2 dependent PRs (#434 , #441 )
• Add config contract #404
• Randomness service: Improve performance and reliability #372
• Add transaction submission failure hook and error handling #366
• Increase default RPC timeout to 2000ms #365
• Add configurable HTTP polling interval for block monitoring #362
• Force initialization before using the TXM #361
• Script to monitor randomness service #325
• Script to easily launch the randomness service locally #324
• Submit drand numbers #318
• Random oracle contracts #307
• Only prune finalized randomness entries #305
• Add NewBlock hook #304
• Refactors the randomness service to be able to process pending commitments  #303
• Add SQLite persistence to randomness service #300 👈 (View in Graphite)
• Txm no longer receives Viem objects #298 : 1 other dependent PR (#299 )
• Add flush mechanism #289 : 1 other dependent PR (#297 )
• Allow run multiple txm simultaneously within the same service #285
• Added docs for txm #272
• Mutex in tx monitor #264
• Purge transactions #232
• Txm hooks #229
• Use kysely instead of mikro-orm #250
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cloudflare-workers-and-pages]

Deploying happychain with    Cloudflare Pages

Latest commit:	3dc92b0
Status:	✅  Deploy successful!
Preview URL:	https://29f72172.happychain.pages.dev
Branch Preview URL:	https://gabriel-db-randomnes-service.happychain.pages.dev

View logs

[linear]

HAPPY-148 randomness-service: Have a database to store the commitments

https://app.graphite.dev/github/pr/HappyChainDevs/happychain/195/First-working-version-of-the-Randomnes-service#comment-PRRC_kwDOMQPPTM5sG9dj

[norswap]

Here's how we can change it: https://github.com/WiseLibs/better-sqlite3/blob/master/docs/integer.md#getting-bigints-from-the-database
I don't think this is Kisely specific, as indicated here: https://kysely.dev/docs/recipes/data-types#configuring-runtime-javascript-types