YAML configuration with integer values cannot be read correctly in Seata

[YvCeung]

Check Ahead

• I have searched the issues of this repository and believe that this is not a duplicate.

• I am willing to try to fix this bug myself.

Ⅰ. Issue Description

Description:
When using a YAML configuration file in Seata, if a configuration item is an integer, Seata fails to read the value correctly.
This issue manifests in two main scenarios:

---

1. Application startup failure due to missing configuration values

During project startup, the SessionHolder initialization logic triggers the database connection pool initialization.
If the configuration file is in YAML format and the database password is an integer, Seata fails to read the value, causing the application to fail to start.

Example YAML configuration:

store:
  db:
    maxConn: 30
    vgroupTable: vgroup-table
    datasource: druid
    minConn: 5
    globalTable: global_table
    lockTable: lock_table
    driverClassName: com.mysql.cj.jdbc.Driver
    user: root
    branchTable: branch_table
    distributedLockTable: distributed_lock
    password: 123456
    queryLimit: 100
    dbType: h2
    url: jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&rewriteBatchedStatements=true
    maxWait: 5000
  publicKey: ""
  mode: db
  session:
    mode: db

When the password is an integer (e.g., 123456), getConfig returns null and the password is not passed to the connection pool, leading to a connection error:
The configuration of code breakpoint reading is as follows:

However, when the password is quoted as a string, it works normally:

password: "aaaaaa"

the data acquisition is normal:

---

2. Configuration change listener fails to read integer values from YAML

In Seata, when listening for configuration changes (e.g., from Nacos), if a changed configuration item is an integer, getProperty fails to retrieve the value and instead returns the default value.

The root cause is in the YAML parsing logic (ProcessorYml).
If the YAML configuration item is an integer, it will be stored in the underlying Properties object as a non-String type.
When code later calls getProperty(...), it returns null because Properties.getProperty only works with String values.
This means:

• For any integer-type configuration item in YAML format
• Retrieved via getProperty (which is the common approach for config center integrations like Nacos, Etcd, etc.)
• The final value will always be null (or fall back to the default value)

---

Unit test evidence:

public class ProcessorYamlTest {

    @Test
    void testProcessor_NormalYaml() {
        String yamlConfig = "server:\n" + "  port: 8080\n"
                + "  host: localhost\n"
                + "spring:\n"
                + "  datasource:\n"
                + "    url: jdbc:mysql://localhost:3306/test\n"
                + "    username: root";

        ProcessorYaml processorYaml = new ProcessorYaml();
        Properties props = processorYaml.processor(yamlConfig);

        assertEquals(8080, props.get("server.port"));
        assertEquals("", props.getProperty("server.port", "")); // fails, returns default
        assertEquals("localhost", props.getProperty("server.host"));
        assertEquals("jdbc:mysql://localhost:3306/test", props.getProperty("spring.datasource.url"));
        assertEquals("root", props.getProperty("spring.datasource.username"));
    }
}

Test result:

• props.get("server.port") → 8080 (integer) ✅
• props.getProperty("server.port", "") → "" (empty string, default value) ❌

---

In addition, I also compared the situation where the configuration file format is properties. I found that whether it is an integer or a String, the properties format file parses to a string. Therefore, the fundamental parsing logic of the two is also different. eg：

Ⅱ. Describe what happened

No response

Ⅲ. Describe what you expected to happen

No response

Ⅳ. How to reproduce it (as minimally and precisely as possible)

No response

Ⅴ. Anything else we need to know?

No response

Ⅵ. Environment

No response