Table of Contents

Class DatabentoLiveBuilder

Namespace
DatabentoDotNet.Extensions.Hosting
Assembly
DatabentoDotNet.Extensions.Hosting.dll

Configures one named live session. Returned by AddDatabentoLive.

public sealed class DatabentoLiveBuilder
Inheritance
DatabentoLiveBuilder
Inherited Members

Fields

DefaultSessionName

The name the no-argument AddDatabentoLive overload uses: Default.

public const string DefaultSessionName = "Default"

Field Value

string

Remarks

A literal name rather than an empty one, so the configuration path is Databento:Live:{name} in every case. The alternative — the single session's keys directly under Databento:Live and named ones beneath it — makes Databento:Live:Dataset and Databento:Live:equities siblings of different kinds, which is ambiguous to read and worse to report an error against.

Properties

Name

The session's name, which is also its configuration key and its service key.

public string Name { get; }

Property Value

string

Services

The collection this session was registered into.

public IServiceCollection Services { get; }

Property Value

IServiceCollection

Methods

AddHealthCheck(string?, HealthStatus?, IEnumerable<string>?)

Registers a LiveSessionHealthCheck reporting this session's state.

public DatabentoLiveBuilder AddHealthCheck(string? name = null, HealthStatus? failureStatus = null, IEnumerable<string>? tags = null)

Parameters

name string

The registration's name, which is what a health-check endpoint reports. Defaults to databento-live-{session}, so two sessions in one host produce two distinct entries without either caller naming one.

failureStatus HealthStatus?

What a stopped or faulted session reports. Defaults to Unhealthy; pass Degraded for a session whose loss should not take the process out of rotation.

tags IEnumerable<string>

Tags the endpoint can filter on, or null for none.

Returns

DatabentoLiveBuilder

This builder.

Remarks

Opt-in, and that is the whole point of it living here. Nothing in AddDatabentoLive registers a check, so a consumer who never calls this gets none — no registration, no probe, no cost. A check installed by default would be one every consumer's /health endpoint reports on whether or not they asked.

Registered straight into HealthCheckServiceOptions rather than through IHealthChecksBuilder. Going through the builder would make the consumer's own AddHealthChecks() a prerequisite — call this first and it would throw, or worse, silently create a second registry. Configuring the options directly means the two compose in either order, which is the same property TryAddSingleton buys for the historical and reference clients.

The registration resolves the keyed LiveSessionRunner lazily, when the check first runs, so calling this does not build a session at registration time.

AddRecordHandler(Func<IServiceProvider, ILiveRecordHandler>)

Registers the handler this session's records are dispatched to, built by a factory.

public DatabentoLiveBuilder AddRecordHandler(Func<IServiceProvider, ILiveRecordHandler> implementationFactory)

Parameters

implementationFactory Func<IServiceProvider, ILiveRecordHandler>

Returns

DatabentoLiveBuilder

AddRecordHandler<THandler>()

Registers the handler this session's records are dispatched to.

public DatabentoLiveBuilder AddRecordHandler<THandler>() where THandler : class, ILiveRecordHandler

Returns

DatabentoLiveBuilder

Type Parameters

THandler

The handler type. Constructed once, as a singleton.

Remarks

A singleton, and that is the dispatch contract rather than a default. A scope per record would allocate, in the one package whose reason to exist is that it does not. A handler needing scoped services opens a scope inside OnFlushAsync(CancellationToken), which is where I/O belongs anyway.