fix(odin): Fix fetch logs result metadata

[vikramlc-cognite]

Summary

Fixes the fetch_logs action so its result metadata can't exceed CDF's 512-byte-per-value limit, and prevents oversized metadata from silently poisoning the checkin batch.

Type of change

• Bug fix (non-breaking change that fixes an issue)

What changed

• cognite/extractorutils/unstable/core/_dto.py: added MAX_METADATA_VALUE_BYTES (512) constant and oversized_metadata_fields() helper to detect metadata dict values exceeding CDF's per-value byte limit.
• cognite/extractorutils/unstable/core/_log_upload_action.py:
  • _FileUploadResult now carries file_id (the numeric CDF file ID returned by upload_bytes), set only when status == "uploaded".
  • Per-file files metadata entries now use the compact numeric id instead of the full file_external_id string, and only include size_bytes for non-uploaded entries - shrinking the payload so it fits within MAX_METADATA_VALUE_BYTES even at MAX_DATE_RANGE_DAYS.
  • Added a size check before attaching files to the result metadata: if the serialized JSON still exceeds the 512-byte limit, it's omitted (with a log line and a note appended to the result message) rather than risking the whole result being rejected. The aggregate counts (total_files, uploaded_files, etc.) are always included regardless.
• cognite/extractorutils/unstable/core/base.py: in _dispatch_single_action, both the success and ActionError paths now check oversized_metadata_fields() before queuing the checkin update:
  • Success path: if any result metadata field is oversized, the action is reported as failed instead (with an explanatory message) rather than queuing a payload Odin would reject.
  • ActionError path: if e.result_metadata has oversized fields, they're dropped and the failure message notes which fields were dropped, instead of sending metadata that would get rejected.
• Tests added/updated in tests/test_unstable/test_action_dispatch.py and tests/test_unstable/test_log_upload_action.py covering all of the above.

Why it changed

• Related issue: EDG-678
• Related docs / discussion: Odin's checkin API rejects the entire batch of pending action updates if any single metadata value exceeds 512 bytes ("Metadata values may be at most 512 bytes"). Because checkin bundles all pending updates and requeues the whole batch on rejection, one oversized files value (previously embedding full file external IDs per day) could poison retries indefinitely for fetch_logs runs over long date ranges.

What to focus on during review

• The reasoning in base.py for turning an otherwise-successful action into a failed checkin update when its result metadata is oversized - confirm this fail-closed behaviour (vs. silently truncating/dropping just the offending field) is the desired tradeoff.
• The fallback behaviour in _log_upload_action.py when files still doesn't fit even after switching to numeric IDs (aggregate counts still reported, files omitted, message annotated).
• Whether omitting file_external_id from per-file entries (replaced by numeric id) is acceptable for any downstream consumers of that metadata field.

Test evidence

• New/updated unit tests: test_oversized_result_metadata_fails_action_instead_of_reporting_succeeded,
  test_oversized_action_error_metadata_drops_metadata_but_keeps_original_message, test_max_range_with_uploads_keeps_files_metadata_within_budget,
  test_files_metadata_omitted_when_still_oversized.

Risks and unknowns

• Any external tooling/dashboards that currently parse file_external_id out of the files metadata field would need to switch to reconstructing it from id/date, or querying CDF by file ID.

Rollout and rollback

• No migrations or config changes. Pure behaviour change in metadata reporting, revertible via normal git revert.

[gemini-code-assist]

Code Review

This pull request introduces size-limit checks on action result metadata to prevent checkin requests from being rejected by CDF due to the 512-byte limit. It implements a helper to detect oversized fields, optimizes log upload metadata by using compact numeric file IDs, and gracefully handles oversized payloads by failing actions or omitting detailed logs. The review feedback suggests making the metadata size helper more robust by casting values to strings before encoding, and refining the error handling to filter out only the oversized metadata fields rather than discarding the entire metadata dictionary.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.86%. Comparing base (20982d7) to head (bde0d3a).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #555      +/-   ##
==========================================
+ Coverage   83.76%   83.86%   +0.09%     
==========================================
  Files          46       46              
  Lines        4627     4661      +34     
==========================================
+ Hits         3876     3909      +33     
- Misses        751      752       +1     

Files with missing lines	Coverage Δ
cognite/extractorutils/unstable/core/_dto.py	98.43% <100.00%> (+0.27%)	⬆️
...extractorutils/unstable/core/_log_upload_action.py	99.26% <100.00%> (-0.74%)	⬇️
cognite/extractorutils/unstable/core/base.py	84.78% <100.00%> (+0.19%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tuanng-cognite]

🦄