Skip to content

[FLINK-38704][runtime] Convert config values to String #27743

Open
mukul-8 wants to merge 1 commit intoapache:masterfrom
mukul-8:FLINK-38704-numeric-config-properties
Open

[FLINK-38704][runtime] Convert config values to String #27743
mukul-8 wants to merge 1 commit intoapache:masterfrom
mukul-8:FLINK-38704-numeric-config-properties

Conversation

@mukul-8
Copy link

@mukul-8 mukul-8 commented Mar 6, 2026

What is the purpose of the change

Fixes the Prometheus metrics reporter (and potentially other reporters) not loading configured port values.

The issue occurs because numeric YAML configuration values are stored as Integer/Long objects, but Properties.getProperty() only returns Strings. When MetricConfig.getString() is called for numeric values like metrics.reporter.prom.port, it returns null, causing reporters to fall back to default values.

Note: The bug only reproduces when a single number is assigned to the port (e.g., 9999). It works correctly when a port-range is used (e.g., 9000-9100) because ranges are stored as Strings.

Safety: This change is safe and non-breaking. Properties are inherently String-based (all values are stored and retrieved as Strings), so converting values to String at insertion time maintains the expected behavior while fixing the type mismatch issue.

Workaround: Quote the port value in YAML configuration: metrics.reporter.prom.port: "9999"

Brief change log

  • Modified addAllToProperties method to convert all configuration values to String before adding to Properties

Verifying this change

This change fixes the bug where:

  • Configuration loads: metrics.reporter.prom.port=9999
  • But reporter starts on default port 9249 instead

After the fix, the configured port is correctly applied.

Added test case to verify this change is working fine.

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
  • The serializers: no
  • The runtime per-record code paths (performance sensitive): no
  • 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
  • If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

…perties

Numeric YAML values are stored as Integer/Long but Properties.getProperty()
only returns Strings. Convert all values to String to fix MetricConfig
getString() returning null for numeric configuration values.
@flinkbot
Copy link
Collaborator

flinkbot commented Mar 6, 2026

CI report:

Bot commands The @flinkbot bot supports the following commands:
  • @flinkbot run azure re-run the last Azure build

entry.getKey().substring(prefix.length(), entry.getKey().length());

props.put(keyWithoutPrefix, entry.getValue());
props.put(keyWithoutPrefix, entry.getValue().toString());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can the entry.getValue() ever be null? Maybe add a test for this case.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. I've verified that entry.getValue() cannot be null. The Configuration.setValueInternal() method ensures only non-null values are stored in the internal map, so entry.getValue() will always return a non-null object at this point.

Copy link
Author

@mukul-8 mukul-8 Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've identified an issue with the current implementation. The .toString() conversion affects complex types like HashMap, which produces non-deterministic string representations due to unordered iteration. This causes the PythonDependencyUtilsTest.testPythonFiles test to fail in CI (though it passed locally due to the non-deterministic nature).

I'll update the implementation to only convert primitive types (Number, Boolean) to String while preserving the original behavior for complex types. This will fix the metrics reporter bug without breaking existing functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants