[FLINK-38449][core] Reject fractional MemorySize values with explicit error

[Jackeyzhe]

What is the purpose of the change

Currently the memory size configuration in Flink accepts numeric values with or without an explicit unit (e.g. 100, 100 bytes, 1k, 1g, 1t), but the error message returned for malformed values is confusing. When a user passes a fractional value such as 1.5g or .5g, the parser first extracts the leading 1 and then fails on the remainder .5g (which is not a valid unit). The error surfaced to the user is NumberFormatException from Long.parseLong, which does not make the actual problem — fractional input — obvious.

This change adds an explicit format check at the top of MemorySize.parseBytes that rejects inputs that do not match the supported shape (an integer, optionally followed by whitespace and a unit). The new error message names the actual problem ("Fractional or malformed values are not supported") and points the user to the expected format ("an integer optionally followed by a unit").

This closes #FLINK-38449 .

Brief change log

• Added a Pattern-based format check at the top of MemorySize.parseBytes (in flink-core-api/src/main/java/org/apache/flink/configuration/MemorySize.java). The regex accepts an integer followed by optional whitespace and a non-space unit suffix; inputs that do not match the supported shape are rejected with a new IllegalArgumentException whose message names the actual problem.
• Added unit-test cases in flink-core-api/src/test/java/org/apache/flink/configuration/MemorySizeTest.java covering the issue's headline examples (.5g and 1.5g) and positive controls (100 and 100 bytes) to confirm that back-compat for no-unit and unit-suffixed inputs is preserved.

Verifying this change

This change added tests and can be verified as follows:

• Run ./mvnw -pl flink-core-api -Dtest=MemorySizeTest test and confirm that the new fractional-input assertions pass, the existing 100 and 100 bytes positive cases still pass, and the pre-existing 1.5g-style assertion (if any) still passes.
• Run ./mvnw -pl flink-core-api test to confirm the broader test suite for the module still passes (no other test in the module should depend on fractional MemorySize input being accepted, but the full module test is the safer check).

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with @Public(Evolving): no (MemorySize is annotated @Public; the change is to an internal validation path of an existing public method, not to the public method's contract — input that was previously accepted with a confusing error is still accepted with a clearer error, and input that was previously rejected with a confusing error is now rejected with a clearer error)
• The serializers: no
• The runtime per-record code paths (performance sensitive): no (the new check is a single compiled-Pattern match, run only at configuration-parse time, not on the hot path)
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? no (this is a usability fix on an existing public method; the method's contract is preserved — the only change is in the error message that callers see on invalid input)
• If yes, how is the feature documented? not applicable

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

[flinkbot]

CI report:

• fcf7a0a UNKNOWN
• 1bd5ed2 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[spuru9]

In the current implementation the unit can be passed as any gebbrish value. Some sort of check on unit if present would help I believe, can you take a look at the stale PR on this https://github.com/apache/flink/pull/27056/changes

[Jackeyzhe]

Thanks for the suggestion. I updated the patch to validate the unit part as well, and then adjusted it to build the accepted unit pattern from MemoryUnit.values() instead of duplicating the unit aliases in the regex.

I also strengthened the invalid-unit test with MemorySize.parseBytes("16 gjah").

Verified with:
./mvnw -pl flink-core-api -Dtest=MemorySizeTest test