Constructor StoredEmailEmbeddingBackfillResult

Namespace

MailFathom.Application.Emails.Embeddings.Backfill

Assembly

MailFathom.Application.dll

StoredEmailEmbeddingBackfillResult(StoredEmailEmbeddingBackfillOutcome, int, int, int, int, int?, EmbeddingGenerationFailure?)

What one run of the embedding backfill did, and why it ended.

public StoredEmailEmbeddingBackfillResult(StoredEmailEmbeddingBackfillOutcome Outcome, int ChunkedEmailCount, int EmbeddedEmailCount, int EmbeddedChunkCount, int CallBudgetExhaustedEmailCount, int? OutstandingEmailCountAtSweepStart, EmbeddingGenerationFailure? Failure)

Parameters

Outcome StoredEmailEmbeddingBackfillOutcome

Why the run ended.

ChunkedEmailCount int

How many messages this run had to cut into passages before anything could be embedded.

EmbeddedEmailCount int

How many messages this run brought up to date, or spent a provider call on.

EmbeddedChunkCount int

How many passages this run committed vectors for.

CallBudgetExhaustedEmailCount int

How many messages this run left part-way through because one turn spent every provider call a turn is allowed.

OutstandingEmailCountAtSweepStart int?

How many messages awaited embedding when this sweep began, or null when the run resumed a sweep somebody else measured.

Failure EmbeddingGenerationFailure?

Why a provider call produced nothing, present exactly when Outcome is ProviderFailed.

Remarks

Counts and classifications only. Every message this run touched, every passage it cut, and every vector it stored is mail content or derived from it, and none of that belongs in something a worker logs.

The exhausted count is carried separately rather than folded into the ordinary progress, because it is the one thing a run does that an operator has to act on and that no other number here would show: the walk steps past such a message and keeps going, so without its own count a mailbox needing several sweeps to finish one message would look exactly like one that is finishing them.