Windows OS.get_unique_id() bug

[hex010]

Tested versions

Git commit hash: 931820d
Git commit hash short: 931820d

System information

Windows 10 - Godot Engine v4.5.dev.custom_build.931820d33 Vulkan 1.4.303 - Forward+ - Using Device #0: NVIDIA - NVIDIA GeForce RTX 4080 SUPER

Issue description

Hello. I got the issue with OS.get_unique_id(). The issue persists only on Windows machine (on Mac machine it is fine). After I print() the value of OS.get_unique_id(), Godot stops displaying any further output in the console (see image 1). However, if I don't print OS.get_unique_id() then all other print() statements will be displayed in the console as expected, like print("HELLO") (see image 2). I also send the value of OS.get_unique_id() to the server and print it there (see Image 3). What I noticed, that the string has some strange character at the end. I suspect that this character might be causing the Godot console to behave incorrectly and suppress further output. Additionally, I checked the log file (see image 4) and it does contain the output of print("HELLO"), even after printing OS.get_unique_id(). However, it also includes that mysterious trailing character. Could this be a bug? Also, why is the unique Windows ID enclosed in curly brackets {}?

Steps to reproduce

Simply write the code as shown in Image 1 (uploaded in the "Issue Description") or use the provided demo project, then check the console log - print("HELLO") will not be visible. Also, check logs and you will see that Windows unique ID contains a special character at the end. Also, a unique Windows ID is enclosed in curly brackets

Minimal reproduction project (MRP)

As you can see in this demo project, "HELLO" is not being printed. Also, the length is shown as 39, but it's actually 38 (due to a hidden character at the end). Additionally, the unique Windows ID is enclosed in curly brackets.
Demo project: test-device-unique-id.zip

[uno1982]

A current work around for now until I hunt this further.
@hex010

func _ready():
	print("Starting script...")
	var device_unique_id = OS.get_unique_id()
	print("Device Unique ID: ", device_unique_id)
	await get_tree().create_timer(0.1).timeout
	print("Checkpoint 1")
	print("Checkpoint 2")
	print("HELLO")

Godot Engine v4.5.dev.custom_build.32eafc18b (2025-04-30 14:18:46 UTC) - https://godotengine.org
OpenGL API 3.3.0 NVIDIA 560.94 - Compatibility - Using Device: NVIDIA - NVIDIA GeForce RTX 2080 Ti

Starting script...
Device Unique ID: {31f37ca4-d489-11ef-8824-806e6f6e6963}
Checkpoint 1
Checkpoint 2
HELLO

[uno1982]

Not sure if its relevant ... but I'm digging in here. editor_log.cpp
if (unlikely(log->is_updating())) { // The new message arrived during log RTL text processing/redraw (invalid BiDi control characters / font error), ignore it to avoid RTL data corruption. return; }

[uno1982]

Ok this might be as designed?

func _ready():
	print("Starting script...")
	var device_unique_id = OS.get_unique_id()
	print_rich(device_unique_id)
	#print("Device Unique ID: ", device_unique_id)
	#await get_tree().create_timer(0.1).timeout
	print("Checkpoint 1")
	print("Checkpoint 2")
	print("HELLO")

The reason it works in console.exe is because that executable properly sets up console output handling and flushes buffers.
print_rich() appears to have different buffering behavior.

[uno1982]

if (_flush_stdout_on_print) {
    // Don't always flush when printing stdout to avoid performance
    // issues when `print()` is spammed in release builds.
    fflush(stdout);
}

So rather than being a bug, this is an intentional performance optimization to prevent excessive flushing when print is called frequently. The print_rich() function works differently because it's primarily intended for the editor's output panel and has different buffering behavior.

@AThousandShips

I do however see this in other areas of code

// Only flush stdout in debug builds by default
GLOBAL_DEF_RST("application/run/flush_stdout_on_print", false);
GLOBAL_DEF_RST("application/run/flush_stdout_on_print.debug", true);

Actually you know what... I almost got blinded by the forest instead of focusing on the tree.

The print_rich() not only handles the buffer differently but also correctly handles special characters and I bet we can resolve this with a wrapper to handle the device_id for the normal print call.

[uno1982]

@AThousandShips you should see that my PR isn't necessarily a bug fix but likely classified as an improvement to editor output window behavior to use the appropriate function based on the stringify results. This reduces the need to explicitly know which print call to use and allows print(value) -> print_rich(value) redirection if needed.

[uno1982]

The issue persists only on Windows machine (on Mac machine it is fine)

As a follow up note:
If the intended behavior is to be able to use function returns in raw format for print calls the OS.get_unique_id() result would be parsed differently due to a mac IOKit likely returning something like 00000000-0000-1000-8000-010203040506

The clue provided by the OP that the print call worked on MAC yet windows presented with curly brackets (and that seemed out of place) helped me derive the improvement. This will handle pretty much any print call where a function is passed that may need to be redirected to rich_print() instead.