Default logger is not emmiting strutured logs

[ParidelPooya]

Is there a reason why the default logger is not emmiting strutured logs?

Durable functions iteself only works with json logging, but the messages itself are in an unstructured format

Example:

context.logger.info(Allocated memory size: ${memoryAllocation.byteLength} bytes);
Produces a message

"info After wait in Parallel Step 1 {\n  timestamp: '2025-11-21T17:18:29.233Z',\n  execution_arn: 'arn:aws:lambda:eu-south-1:713881787121:function:my-first-durable-function:$LATEST/durable-execution/4969cfc7-b2d2-4895-b03d-38ee99f2dcd6/8523dcfc-3174-3422-a5d0-3e05669181a5',\n  level: 'info',\n  step_id: '19a1de167122a18a',\n  message: 'After wait in Parallel Step 1'\n}"
which is a composition of
info After wait in Parallel Step 1 
and
{\n  
timestamp: '2025-11-21T17:18:29.233Z',\n  
execution_arn: 'arn:aws:lambda:eu-south-1:713881787121:function:my-first-durable-function:$LATEST/durable-execution/4969cfc7-b2d2-4895-b03d-38ee99f2dcd6/8523dcfc-3174-3422-a5d0-3e05669181a5',\n  
level: 'info',\n  
step_id: '19a1de167122a18a',\n  
message: 'After wait in Parallel Step 1'\n
}

which then again gets wrapped in

{
    "timestamp": "2025-11-21T17:18:29.233Z",
    "level": "INFO",
    "requestId": "dc7b3f6b-608d-459b-89dd-9bdf5144c7d9",
    "message": "info After wait in Parallel Step 1 {\n  timestamp: '2025-11-21T17:18:29.233Z',\n  execution_arn: 'arn:aws:lambda:eu-south-1:713881787121:function:my-first-durable-function:$LATEST/durable-execution/4969cfc7-b2d2-4895-b03d-38ee99f2dcd6/8523dcfc-3174-3422-a5d0-3e05669181a5',\n  level: 'info',\n  step_id: '19a1de167122a18a',\n  message: 'After wait in Parallel Step 1'\n}"
}
``
What I would expect to see is

{
"timestamp": "2025-11-21T17:18:29.233Z",
"level": "INFO",
"requestId": "dc7b3f6b-608d-459b-89dd-9bdf5144c7d9",
"message": "info After wait in Parallel Step 1",
//
"execution_arn": "arn:aws:lambda:eu-south-1:713881787121:function:my-first-durable-function:$LATEST/durable-execution/4969cfc7-b2d2-4895-b03d-38ee99f2dcd6/8523dcfc-3174-3422-a5d0-3e05669181a5",
"step_id": "19a1de167122a18a"
}

Not only does that save money because it is not storing duplicated data, its also easier to query :smiley:

[embano1]

@ParidelPooya I think this is fixed and can be closed? I'll create another issue for the \n JSON serialization.