feat(console): split long messages for os_log and report errors as errors - #530

What is the current behavior?

os_log silently truncates long messages with <…> at about 1 KB. console.error is logged at the default level, so log readers can't tell errors apart.

What is the new behavior?

• Messages over 900 bytes are split (LogChunks.h), at line breaks when possible and never inside a UTF-8 sequence. Without the CLI's key below, each piece is a plain line with the console prefix repeated.
• console.error and failed assertions use OS_LOG_TYPE_ERROR.
• When the CLI writes "logFormat": 1 to the app's package.json and stdout is /dev/null, each piece is logged as [ns <id> <index>/<count>] <piece>. The id is unique per message in the process, and the pieces are exact slices of the message: only the first carries the console prefix. The CLI groups pieces by message id, prints a message as soon as its last piece arrives, and shows <…lost…> where pieces never arrived. It never joins the next message onto an unfinished one.
• The unified log strips whitespace from the end of every entry, so a piece never ends in whitespace: the cut moves before it and the whitespace starts the next piece, after its header.
• logFormat is the newest format the CLI understands. The runtime uses the lower of that and its own, so either side can add a format 2 later.

The key and the stdout check keep the headers to readers that understand them. Older CLIs never write the key, and an attached console fails the stdout check, so older CLIs and Xcode see plain split lines. The new CLI removes the headers when a device falls back to the syslog relay.

The runtime is prebuilt through SwiftPM, so a build setting can't reach it, and adding a build setting would relink. A package.json key costs only a re-sign.

Testing

The table below was run on the first version of this PR, which marked chunks with invisible characters. A demo app logged 11 messages (up to 100 KB, emoji, 800 lines, console.error, objects), compared exactly against the expected text on both launches of each run:

Also confirmed with simctl launch --console-pty: markers stay off with a console attached. Launching from Xcode itself wasn't tested.

After the switch to logFormat (simulator only, iPhone 16 Pro, iOS 26.3):

• The TestRunner suite passes: 1,835 tests, 0 failures.
• 30,000 random messages (UTF-8, line breaks, runs of spaces and tabs) split and join back exactly, with every entry's trailing whitespace stripped as the unified log does.
• The test app, launched with stdout on /dev/null, logged 62 long messages from the main thread, two workers and forwarded stdout at the same time. Passing the captured log stream through the CLI's code rebuilt all 62 exactly, with no header left in the output. With an extra 2 MB message, all 61 checked messages still came through.
• Not rerun on the iPad.

Known limit: in a probe with three threads logging while another logged 2 MB, about a third of the threads' chunks never reached the stream. Losses like that still happen, but pieces are now numbered, so the CLI shows <…lost…> where they belong instead of a silent gap. The 2 MB run above lost nothing, so that path is covered by the CLI's unit tests only.

Part of a stack

1. fix(build): stop forcing a relink on every incremental build #529
2. This PR

Next: #532. The CLI side is NativeScript/nativescript-cli#6179.

Summary by CodeRabbit

• Logging
  • Console messages and failed assertions are sent to the operating system’s logging service when available, with errors marked at error severity.
  • Long messages are divided into smaller chunks while preserving UTF-8 characters. When the configured log format supports it, chunk markers help identify message order and continuation.
  • When operating system logging is unavailable, messages continue to use the existing logging path.