[KYUUBI #7244][SERVER] Skip invalid batch metadata during recovery

[hutiefang76]

Why are the changes needed?

Null-valued batch configuration entries can reach persisted batch metadata and later fail when KyuubiBatchSession copies requestConf into KyuubiConf, whose set(key, value) rejects null values.

The fix now covers the full lifecycle instead of turning a recovery-time validation error into a terminal batch state:

• filter null-valued configuration at the REST creation boundary, before user/batch-id lookup and V2 metadata persistence;
• sanitize configuration and the attached metadata at the shared createBatchSession boundary, covering V1 creation, V2 INITIALIZED submission, and PENDING/RUNNING recovery;
• keep unrelated recovery failures on their existing retry/error path rather than broadly converting them to ERROR.

The shared sanitizer also provides compatibility for legacy metadata that already contains a null value.

How was this patch tested?

• Added BatchesResourceSuite coverage proving V1 and V2 requests persist metadata without the null-valued entry.
• Added KyuubiSessionManagerSuite coverage for both INITIALIZED submission and PENDING/RUNNING recovery; the batch remains recoverable and the null key is absent from the session configuration.
• Targeted lifecycle suite: 2 tests passed, 0 failed.
• REST V1/V2 suites: the 2 new tests and 26 other tests passed. Two existing open batch session log assertions failed because the local Spark fixture did not emit Submitted application: Spark Pi; the same two failures were reproduced on a detached clean origin/master worktree with the same SPARK_HOME.
• dev/reformat
• git diff --check

Was this patch authored or co-authored using generative AI tooling?

Assisted-by: OpenAI Codex

Bug history and affected versions

• General batch-session recovery was introduced by KYUUBI [SUB-TASK][KPIP-4] Support to recovery batch session on Kyuubi instances restart #2373 and is present from the 1.6.0-incubating release line onward.
• Batch API V2 was introduced by KYUUBI Initial implement Batch V2 #4790 and is present from the 1.8.0 release line onward. The reported V2 path is therefore confirmed for 1.8.0+ and current master.
• Current master also has the explicit batch reassignment recovery path added by KYUUBI [FEATURE] Support to reassign the batches to alternative kyuubi instance in case kyuubi instance lost  #6884; the shared session-creation sanitizer covers both normal startup recovery and explicit batch-id recovery.

[pan3793]

has this bug been fixed? if so, document the history and the affected version

[hutiefang76]

Yes. I documented the history and affected versions in the PR description and verified them from the repository tags: batch-session recovery was introduced by KYUUBI #2373 (first released in 1.6.0-incubating), while Batch API V2 was introduced by #4790 (first released in 1.8.0). The reported V2 recovery failure is therefore confirmed for 1.8.0+ and current master. #6884 later added the explicit batch-reassignment recovery path; the helper in this PR guards both normal startup recovery and that reassignment path.

[pan3793]

what I mean bug fix is, filtering out the null-valued config when creating the batch ...

I remember having fixed it, seems not to have been pushed to upstream ...

[hutiefang76]

Thanks for clarifying. I reworked the patch around creation-time filtering in 34dcff8:

• The REST boundary removes null-valued entries before user/batch-id lookup and V2 metadata persistence.
• The shared createBatchSession boundary sanitizes both the configuration and attached metadata, so legacy INITIALIZED submission and PENDING/RUNNING recovery are covered as well.
• The previous broad recovery catch/ERROR transition was removed; unrelated recovery failures keep their existing behavior.

I added separate tests for REST persistence, INITIALIZED submission, and recovery. The targeted lifecycle suite passes 2/2; the new REST test passes in both V1 and V2 suites. I also documented the full test evidence, including the two unrelated Spark log-fixture failures reproduced on clean origin/master, in the PR description.

[hutiefang76]

Thanks for the reminder. I updated the PR description with the history and affected-version scope: general batch-session recovery exists from 1.6.0-incubating+, Batch API V2 was introduced in 1.8.0+, and this issue is confirmed for the reported Batch V2 path on 1.8.0+ and current master. The patch also guards the current master explicit batch reassignment recovery path added later.

[wangzhigang1999]

Thanks for the fix. It addresses the recovery failure, but I’m still concerned about the full lifecycle of invalid metadata, so I’d prefer to hold off on merging for now.