Patch up docs

Author: OussamaSaoudi-db

kernel/src/table_changes/log_replay.rs

@@ -81,9 +81,10 @@ pub(crate) fn table_changes_action_iter(
 ///       phase, so we must perform it ahead of time in phase 1.
 ///     - Ensure that reading is supported on any protocol updates.
 ///     - Extract the in-commit timestamps from [`CommitInfo`] actions if they are present. These are
-///       generated when in-commit timestamps table feature is enabled. This must be done in the
+///       generated when in-commit timestamps (ICT) table feature is enabled. This must be done in the
 ///       first phase because the second phase lazily transforms engine data with an extra timestamp
-///       column, so the timestamp must be known ahead of time.
+///       column, so the timestamp must be known ahead of time. Note that when ICT is enabled, CommitInfo
+///       should be the first action in  every commit.
 ///       See: https://github.com/delta-io/delta/blob/master/PROTOCOL.md#in-commit-timestamps
 ///     - Ensure that Change Data Feed is enabled for any metadata update. See  [`TableProperties`]
 ///     - Ensure that any schema update is compatible with the provided `schema`. Currently, schema
@@ -119,8 +120,8 @@ struct LogReplayScanner {
     // The commit file that this replay scanner will operate on.
     commit_file: ParsedLogPath,
     // The timestamp associated with this commit. This is the file modification time
-    // from the commit's [`FileMeta`]. If there is a [`CommitInfo`] with a timestamp
-    // generated by in-commit timestamps, that timestamp will be used instead.
+    // from the commit's [`FileMeta`]. If in-commit timestamps feature is enabled, this will be the
+    // in-commit timestamp from the [`CommitInfo`] action.
     timestamp: i64,
 }