Open log service: batched data-log path drops DataLogMessage.schema_logs (DML-embedded schema ops lost) #494

Summary

In the open log service, the batched write path that handles all kDataLog requests collects only node_txn_logs and never processes DataLogMessage.schema_logs. DML-embedded schema operations are therefore never persisted into the log state, and the non-batched code path that does handle them is unreachable for data logs.

Details

log_service/src/open_log_task.cpp:

• Batched path (WorkerThreadMain, lines ~85-123): every kWriteLogRequest whose content is kDataLog is routed into the batch — the loop copies data_log.node_txn_logs() into batch_logs and calls log_state_->AddLogItemBatch(batch_logs). data_log.schema_logs() is never read.
• Non-batched handler (HandleWriteLog, lines ~230-246) does call log_state_->UpsertSchemaOpWithinDML(...) when schema_logs is non-empty — but the second pass in WorkerThreadMain marks every data-log task as is_batched_data_log and answers it from batch_err, so this branch is dead code for data logs.

Impact

Any transaction that piggybacks schema ops on a data log (the schema_logs field of DataLogMessage, see tx-log-protos/log.proto) silently loses those schema ops in the WAL. On failover/replay, recovery will not see them — potential schema/data inconsistency after recovery. (Whether the tx_service currently emits non-empty schema_logs on this path determines today's blast radius, but the contract is broken either way.)

Suggested fix

In the batched first pass, check data_log.schema_logs() and either (a) call UpsertSchemaOpWithinDML for those tasks before/with the batch write, or (b) exclude tasks with non-empty schema_logs from batching so they fall through to HandleWriteLog.

Found during the module-docs review (#493); see docs/10-log-service.md.

🤖 Found with Claude Code