fix: TAP-10529 inaccurate statistics of output indicators in share cd…

[mnianqi]

…c task

[augmentcode]

🤖 Augment PR Summary

Summary: This PR adjusts how observable metric handlers are managed in order to address inaccurate output indicator statistics in shared CDC tasks.

Changes:

• Switches per-table, per-data-node, and per-processor handler maps from eager initialization to lazy initialization
• Adds null-guards when stopping the task before closing handler instances
• Initializes handler maps on-demand when init/table-count aspects are processed

Technical Notes: The handler map lifecycle is now dependent on which aspects are actually observed during a task run, which affects when these maps may be null.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 3 suggestions posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

Since tableSampleHandlers now starts as null, any direct dereference can throw NPE (e.g. handleSnapshotWriteTableCompleteFunc uses tableSampleHandlers::get when sourceTableName is non-null). This seems reachable if table-count/handler initialization never happened for a run but snapshot completion still fires.

Severity: high

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[augmentcode]

With dataNodeSampleHandlers now nullable, several handlers still call dataNodeSampleHandlers.get(...) without a prior null-check (e.g. handleBatchSize, handleDataNodeClose). If any of those aspects can occur before handleDataNodeInit (or in flows where init isn’t observed), this will NPE.

Severity: medium

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[augmentcode]

processorNodeSampleHandlers is now nullable, but handleProcessorNodeClose/handleProcessorNodeProcess dereference it via processorNodeSampleHandlers.get(nodeId) without guarding for null. If close/process aspects can be emitted without a prior init being observed, this will NPE.

Severity: medium

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}