[OIiveirra]

What problem does this PR solve?

Issue Number: N/A

Related PR: #69478 (backport to branch-4.2)

Problem Summary: When a Hudi JNI scan uses explicit S3A credentials, enabling scanner DEBUG logging prints every parameter value, including access keys, secret keys and session tokens. Log parameter names without values and record the query ID separately so scans remain traceable. The Hadoop configuration used to read data is unchanged.

Add a regression test that captures the real scanner's DEBUG output, checks that parameter names and the query ID remain visible, rejects ordinary and bucket-specific credentials and custom tokens, and verifies that Hadoop properties retain their original values.

Release note

Hudi JNI scanner debug logs no longer include storage credential values and continue to include query IDs for diagnostics.

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test
  • No need to test or manual test.

  Validation with JDK 17:

  • EXTRA_FE_MODULES=hudi=be-java-extensions/hadoop-hudi-scanner ./run-fe-ut.sh --run 'org.apache.doris.hudi.HadoopHudiJniScannerLogTest,org.apache.doris.hudi.HadoopHudiColumnValueTest,org.apache.doris.hudi.HudiUuidTransportTest': 9 tests passed.
  • The log regression test verifies query ID retention, credential-free DEBUG output and unchanged Hadoop properties.
  • The test captures this branch's Log4j/reload4j backends.
  • Maven validate / Checkstyle for be-java-extensions/hadoop-hudi-scanner and its dependencies, plus git diff --check: passed.
  • The logging regression is covered directly by JUnit. FE/BE + S3 end-to-end regression was not run locally; SQL planning, credential propagation and data-reading logic are unchanged.

• Behavior changed:

  • No.
  • Yes. DEBUG logs retain parameter names and query IDs without printing other parameter values.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[OIiveirra]

run buildall

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 100% (0/0) 🎉
Increment coverage report
Complete coverage report

[OIiveirra]

run cloud_p0

[OIiveirra]

/review

[github-actions]

Reviewed the complete two-file PR diff at 6463c9a. No actionable introduced defects found. The review converged in one round: the complete-review agent and separate credential-provenance risk agent both returned NO_NEW_VALUABLE_FINDINGS, and all candidates and risk items have evidence-backed dispositions.

The constructor logs parameter names and the runtime-generated query ID while omitting other parameter values. I traced HudiScanNode properties through both legacy and format_v2 BE JNI readers, JNI map transport, scanner construction, authentication, reader Properties and JobConf. Both callers generate the query ID from numeric runtime fields; catalog properties cannot overwrite that raw parameter. Hadoop credential values retain their original downstream configuration flow.

Individual critical checkpoint conclusions:

1. Goal and test: the added test captures the real scanner category, requires DEBUG visibility, checks query/key output, rejects ordinary and bucket-specific S3A access/secret/session values plus a custom token, and compares the exact Hadoop map. Static inspection supports the intended constructor logging fix.
2. Scope: the production change is limited to two logging statements, with one focused regression test.
3. Concurrency and locks: no new production thread, shared mutable state or lock ordering; test capture uses a thread-safe list and scoped logger settings. No competing logger mutation was identified in this module's tests.
4. Lifecycle and initialization: no new production static initialization dependency or retained resource; capture cleanup removes appenders and restores saved settings even on assertion failure. The constructor-only test opens no reader or native vector table.
5. Configuration: no new setting or dynamic-configuration behavior; original Hadoop values still populate fsOptionsProps.
6. Compatibility: constructor interfaces, function symbols, protocols and storage formats are preserved; an absent query ID is safe to format.
7. Thrift/protobuf: no definition changes requiring cross-release field/enum checks.
8. Parallel paths: both legacy and format_v2 JNI readers share this Java scanner and receive the fix. Native reader paths are unaffected.
9. Conditions: existing prefix extraction and DEBUG guard remain valid; the query-ID message uses parameterized logging.
10. Coverage: positive diagnostics, multiple credential families, arbitrary Hadoop values and configuration preservation are covered by assertions. Inherited Log4j APIs and JUnit Vintage support the test's dependencies; existing constructor tests remain compatible by inspection.
11. Expected results: no generated output files changed; no build or test result is independently claimed here.
12. Observability: query correlation and parameter names remain available at DEBUG. The local logging change requires no new metric or INFO event.
13. Persistence and failover: no EditLog, transaction, replay, visibility-version or failover behavior changes.
14. Writes and crash behavior: no data-write or atomicity change; existing reader exception/close behavior is preserved.
15. FE/BE variables: no new transmitted variable; both BE builders already supply query_id.
16. Performance and memory: the parameter loop remains linear; one constant-time map lookup/DEBUG event is added, and parameter values are no longer formatted. No significant new allocation or tracking concern found.
17. Further recheck: verified property-name/query-ID collisions, missing IDs, logging bridge/capture behavior, authenticator side effects, remaining scanner logs and alternate JNI callers. No additional introduced issue remained; data/version/delete-bitmap invariants are unaffected.

There were no existing inline threads or additional user focus points. There are no accepted inline findings, existing blocking comment IDs, unresolved candidates or uncovered changed files. Validation is static-only as required: builds, unit tests and live S3/Kerberos/end-to-end scans were not run. This conclusion concerns the changed constructor parameter logging, without asserting that third-party or pre-existing exception logs are scrubbed.

Review converged after 1 round(s).

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 0.00% (0/181) 🎉
Increment coverage report
Complete coverage report