Skip to content

[REQUEST] Add an eventStore.backend setting and build event repositories in one place #802

Closed

Description

@Anshumancanrock

Is your feature request related to a problem? Please describe.

Every event goes to PostgreSQL, and there is no way to point the relay at another store. Nine places construct EventRepository directly: the relay worker, the maintenance, static mirroring, relay monitor and DVM orchestrator workers, the payments service, the invoice and admission controllers, and the import command. Adding a second store today would mean changing all of them.

Describe the solution you'd like

  • Add an eventStore.backend setting. It defaults to postgres, the only value for now, so existing relays behave the same.
  • Add a createEventRepository factory and build every event repository through it.
  • Read the setting once at startup. The primary checks it before forking and passes it to every worker, including workers re-forked after a crash.
  • Refuse to start on an unsupported value, and report it from validateSettings so the admin API and nostream config reject it too.

Describe alternatives you've considered

  • Reading the setting wherever a repository is built. Client workers reload settings.yaml while running, and the invoice, admission and payment-callback handlers build a repository on every request, so an edit could split a running relay across two stores and a typo would make those endpoints return 500.
  • Caching it once per worker process. A worker re-forked after a crash would then read the edited file and could disagree with the workers still running.

Additional context
This is the first step toward serving events from strfry's LMDB store behind the existing IEventRepository interface. The strfry backend itself, and the four places that query the events table directly (the export script, clean-db, the query benchmark and nostream info), come in follow-up PRs.

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

Metadata

Metadata

Labels

enhancementNew feature or request

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions