[LIVY-1083] Coerce batch/session Int fields sent as JSON strings

[soumyadeeplogin]

What changes were proposed in this pull request?

CreateBatchRequest and CreateInteractiveRequest declare driverCores, executorCores and numExecutors as Option[Int]. Because of Scala type erasure, Option[Int] erases to Option[Object], so jackson-module-scala cannot tell the element type is Integer. When a client sends one of these fields as a JSON string (e.g. "4" instead of 4), Jackson stores it verbatim as Some("4") without error. The bad value only surfaces later as a ClassCastException when the code unboxes it to Int while building the Spark submit command, which the servlet returns to callers as an opaque HTTP 500.

This PR annotates the three fields on both request classes with @JsonDeserialize(contentAs = classOf[java.lang.Integer]) so Jackson coerces numeric strings to Int during deserialization, and rejects truly non-numeric strings with a client-facing 400 (JsonMappingException) instead of a 500 later during app creation.

Why are the changes needed?

To fail fast with a clear 400 at the API boundary when a client sends a malformed numeric field, instead of an opaque 500 deep in Spark app submission logic.

Does this PR introduce any user-facing change?

Yes, but only for previously-broken input. POST /batches and interactive session creation now accept JSON string values for driverCores/executorCores/numExecutors (e.g. "4") by coercing them to the equivalent int, and return a 400 instead of a 500 for genuinely non-numeric strings (e.g. "notanumber", "4.5").

How was this patch tested?

Added unit tests to CreateBatchRequestSpec and CreateInteractiveRequestSpec covering: numeric-as-JSON-number (unchanged behavior), numeric-as-JSON-string (coerced), non-numeric string (400/JsonMappingException), empty string (None), whitespace-padded numeric string (coerced), and fractional numeric string (rejected).

Ran mvn -pl server -am test -DwildcardSuites=org.apache.livy.server.batch.CreateBatchRequestSpec,org.apache.livy.server.interactive.CreateInteractiveRequestSpec; all 14 tests pass.

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

Yes, this patch was co-authored using Claude Code (Anthropic).

[soumyadeeplogin]

Filed LIVY-1083 for this change.

[soumyadeeplogin]

Hi @gyogal / @roczei — could one of you approve the pending CI workflow run for this PR (fork-contributor approval gate)? Happy to address any review feedback as well. Thanks!

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.10%. Comparing base (501e822) to head (015c296).
⚠️ Report is 12 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #558      +/-   ##
============================================
+ Coverage     68.68%   73.10%   +4.41%     
- Complexity     1218     1295      +77     
============================================
  Files           106      106              
  Lines          6815     6874      +59     
  Branches        836      855      +19     
============================================
+ Hits           4681     5025     +344     
+ Misses         1666     1344     -322     
- Partials        468      505      +37     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gyogal]

Thanks for your contribution @soumyadeeplogin ! I am still testing/reviewing, but I do agree it is better to send HTTP 4xx instead of 5xx on malformed client input. However the downside is some existing clients may already check for HTTP 5xx in this case, so in this rare case it would be an API change. This may not be a big issue (especially prior to the 1.0 release), I just wanted to point it out.

[soumyadeeplogin]

Thanks for the careful look, @gyogal! Good news — this doesn't actually change the status code either way. Malformed/non-coercible input (e.g. "driverCores": "abc") already returned HTTP 400 before this PR, and still does after it.

JsonServlet.scala has a shared Scalatra error handler used by both batch and interactive session creation:

error {
  case e: JsonParseException => BadRequest(e.getMessage)
  case e: UnrecognizedPropertyException => BadRequest(e.getMessage)
  case e: JsonMappingException => BadRequest(e.getMessage)
  case e =>
    SessionServlet.error("internal error", e)
    InternalServerError(e.toString)
}

Jackson's InvalidFormatException/MismatchedInputException (thrown for a genuinely non-coercible string like "abc") are both subclasses of JsonMappingException, so they're already caught by the BadRequest branch, not the generic 500 fallback. @JsonDeserialize(contentAs = classOf[java.lang.Integer]) only widens what Jackson successfully coerces (numeric strings like "4" now succeed instead of erroring) — it doesn't touch this error handler and doesn't change the exception type thrown for values that still fail. So there's no client-facing status-code change or API-compatibility concern here.