An engineer ingests a JSON event feed into a Microsoft Fabric Eventhouse table. Ingestion reports failures, and the ingestion failures view shows the reason 'BadRequest_MappingError' for the affected rows while other rows land correctly. The source recently added a nested field that does not exist as a column in the target table. The engineer must get the new field stored without dropping the rows that are still failing. Which action resolves the mapping error described?
- ALower the table's ingestion batching latency so smaller batches are committed more often, giving the affected rows another chance to be parsed successfully.
- BIncrease the ingestion timeout so the engine has longer to process the larger payloads, which lets the previously failing rows complete their ingestion.
- CUpdate the ingestion mapping and table schema to add a column for the new nested field, mapping its JSON path so the previously rejected rows ingest correctly. Correct
- DPause the source Eventstream and resume it so the connection re-reads the feed from the beginning and re-applies the existing mapping to the failed rows.
Why A is wrong: Batching latency only controls how often data is committed, not how fields map to columns; the rows fail because a referenced field has no target column, which more frequent batches cannot fix.
Why B is wrong: A mapping error is a schema mismatch raised immediately during parsing, not a slow operation; extending the timeout does nothing because the rows are rejected on validation rather than timing out.
Why C is correct: The mapping error is raised because the JSON references a field that has no matching column and path in the mapping; adding the column and mapping the nested JSON path lets the engine place the value and ingest the rows that were failing.
Why D is wrong: Replaying the same feed against the same mapping reproduces the same mismatch, so the rows fail again; the error is in the mapping definition, which a restart leaves unchanged.