mirror of
https://github.com/okieselbach/AutopilotMonitor.git
synced 2026-10-24 04:32:32 +00:00
d0cb7e66f4
Every entity-group transaction was chunked by count only; 100 payload-heavy rows (Signals with chunked PayloadJson, Events with 30k-char Message + DataJson) could exceed the 4 MiB transaction cap, and the failure surfaced as an opaque 500. The agent halves its batch only on 413 and treats 5xx as "replay later", so such a batch wedged the device forever. - TableTransactionBatcher: 100 actions, 3.5 MB per transaction, 1 MB per entity, never across partitions; an entity that cannot fit throws TableEntityTooLargeException. Used by the event, signal, transition, restore and rules writers; delete-only batches keep their count chunking. - StorageErrors: one classifier for RequestFailedException (transient 408/429/ 5xx, payload-too-large by status or error code, already-exists incl. the Azurite 400 shape); the two IsAlreadyExistsStatus copies use it. - Event writer: per-row fallback only for data-shaped rejections; throttling, outages and oversize batches propagate. Single and batched writer share one entity builder. - IngestTelemetryFunction: payload too large -> 413, transient -> 503 with Retry-After: 5, anything else 500. - TableStorageChunking.MaxPropertyChars is the one 30,000-char bound. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>