Table of Contents

Method AddOnnxIngestion

Namespace
Qavren.Edge.Ingestion.Onnx
Assembly
Qavren.Edge.Ingestion.Onnx.dll

AddOnnxIngestion(EdgeBuilder, string?, Action<ResourceMonitorThrottleOptions>?)

Registers EdgeChunkTokenizer and ResourceMonitorThrottle, and derives ChunkOptions.MaxTokens / OverlapTokens / MinTokens from the resolved EmbeddingPreset unless the consumer already set them. This is the call that stops a constant from hiding a truncation. Idempotent; order-independent relative to AddOnnxEmbeddings.

public static EdgeBuilder AddOnnxIngestion(this EdgeBuilder builder, string? embeddingsName = null, Action<ResourceMonitorThrottleOptions>? configure = null)

Parameters

builder EdgeBuilder

The Qavren.Edge builder.

embeddingsName string

The keyed AddOnnxEmbeddings registration, or null for the unkeyed one.

configure Action<ResourceMonitorThrottleOptions>

Configures the throttle.

Returns

EdgeBuilder

The builder, for chaining.

Remarks

Everything here resolves lazily, so the builder call touches neither the generator nor the vocabulary. The preset is read from the generator through generator.GetService(typeof(EmbeddingPreset)) - the same route SP2's own store uses - and projected onto ChunkModelProfile; the projection is applied to every AddIngestion registration whose StoreName equals embeddingsName. Two guards, because a default that silently disagrees with reality is worse than no default: a Model the consumer set explicitly whose Id, Dimensions, MaxSequenceLength, DocumentPrefix or QueryPrefix differs from the preset is IngestionOptionsInvalid (6005) naming both, never overwritten; and a profile left at its default whose collection was declared at a width the preset does not have is 6005 too, because the DDL is already registered.

The tokenizer is built asynchronously by a startup task at order Validate - 10, so the core's order-400 task finds it already cached and blocks on nothing. Resolving IChunkTokenizer before the host has started still works, and blocks on SP2's provisioning.

The throttle registration is appended, so it wins over the core's FixedIngestionThrottle whichever of AddIngestion and this call comes first. A consumer's own UseIngestionThrottle wins when it is chained AFTER this call.