When logging, the message gets lost if there is another message in KeyValue

[manuranga]

Description

If there is another filed called message the original message will get overridden.

Steps to Reproduce

import ballerina/log;

type MyMessage record {|
    string message;
|};

public function main() {
    MyMessage myMessage = { message: "secondary message" };
    log:printInfo("main message", (), (), myMessage);
}

time=2025-09-10T15:55:53.001+05:30 level=INFO module=manu/log_bug message="secondary message"

Version

Ballerina 2201.9.2 (Swan Lake Update 9)

Environment Details (with versions)

No response

[Better-Boy]

@daneshk
Code - https://github.com/ballerina-platform/module-ballerina-log/blob/master/ballerina/root_logger.bal#L134

Possible solutions:

1. Rename the key in the KeyValue to something else
2. Convert the KeyValue separately to a string and then append it to the message key in the LogRecord

If there are better ideas, we can discuss it.

Can you assign this issue to me?

[daneshk]

Thanks for the interest @Better-Boy. I assigned the issue to you.

How about preventing message from being a key in the Key-Value record?

1. https://github.com/ballerina-platform/module-ballerina-log/blob/master/ballerina/natives.bal#L51

[Better-Boy]

@daneshk Please review PR - ballerina-platform/module-ballerina-log#1379

[TharmiganK]

@daneshk Please review PR - ballerina-platform/module-ballerina-log#1379

With the above change, the example provided will have a compilation error saying the MyMessage is not log:KeyValues. Also we are allocating two field names for message which is unnecessary

@Better-Boy There are two records in this case:

1. The record exposed as the type of the key-value pairs which can be added to the log statement:

   public type KeyValues record {|
       never msg?;
       never 'error?;
       never stackTrace?;
       Value...;
   |};

   Plesae note that we are clearly allocating special key names which are same as the log print function parameter names. Those parameter names cannot be part of the included parameter type: KeyValues, otherwise it will create a confusion. Thats why the KeyValue type is defined with never type for those field names.

2. An internal record which is used to create the values to be printed from the log print functions

   type LogRecord record {
       string time;
       string level;
       string module;
       string message;
       FullErrorDetails 'error?;
   };

   Please note the field name which represents the log message. It is defined as message and not msg

As you have already spotted, the LogRecord is created here. And the message is first set from the msg field and then overwritten by the fields in the key-value pairs.

So IMO the actual fix should be done by considering the differences in these records. And we need to think of a non breaking change for the existing users.

[Better-Boy]

@TharmiganK yes, during my testing it led to compile time error.

There are 2 ways I can think of:

1. As per my earlier comment - Convert the KeyValue separately to a string and then append it to the message key in the LogRecord
2. How about we check if the key is message and append it to existing message key in the logrecord instead of replacing it?

foreach [string, Value] [k, v] in keyValues.entries() {
    Value value = v is Valuer ? v() :
                  v is PrintableRawTemplate ? processMessage(v) :
                  v;

    if k == "message" {
        // Append the key name and value to the existing log message, separated by a comma
        logRecord["message"] = logRecord["message"].toString() + ", " + k + ": " + value.toString();
    } else {
        logRecord[k] = value;
    }
}

output:

message = Order processed, message: delayed due to network issue, id = 42

let me know your thoughts.

[TharmiganK]

IMO appending the custom message to the message field is not correct. The problem here is we have used the field name msg instead of message in the print functions and KeyValues record. But fixing that name now is a breaking change. May be for now we can ignore the new message by providing a warning or use a different key to represent the messages with the message field name.

@daneshk @ThisaruGuruge Appreciate your inputs on this