[GRPC] Monitor does not emit `applied_settings` response after changing the baudrate

[dankeboy36]

Describe the problem

Hello, I am using the CLI daemon with JS, and after updating the baudrate of the monitor, the client does not receive the corresponding response:

arduino-cli/rpc/cc/arduino/cli/commands/v1/monitor.proto

Lines 60 to 63 in c41f5df

	// Settings applied to the port, may be returned after a port is opened (to
	// report the default settings) or after a new port_configuration is sent
	// (to report the new settings applied).
	MonitorPortConfiguration applied_settings = 3;

I had expected to see this response after changing the baudrate, but it never occurred. Is it a bug?

To reproduce

Inside the arduino-cli repo, generate the .proto files with buf:

buf export . -o ./tmp/out

Start the Arduino CLI in daemon mode:

./arduino-cli daemon
Daemon is now listening on 127.0.0.1:50051
{"IP":"127.0.0.1","Port":"50051"}

Open another shell and change the directory to the local Git clone of the Arduino CLI repository.

Create an instance:

grpcurl \
  -plaintext \
  -import-path ./tmp/out \
  -proto cc/arduino/cli/commands/v1/commands.proto \
  127.0.0.1:50051 \
  cc.arduino.cli.commands.v1.ArduinoCoreService.Create
{
  "instance": {
    "id": 1
  }
}

Initialize the instance:

grpcurl \
  -plaintext \
  -import-path ./tmp/out \
  -proto cc/arduino/cli/commands/v1/commands.proto \
  -d '{"instance": {"id": 1}}' \
  127.0.0.1:50051 \
  cc.arduino.cli.commands.v1.ArduinoCoreService.Init

Start the monitor:

grpcurl \
  -plaintext \
  -import-path ./tmp/out \
  -proto cc/arduino/cli/commands/v1/commands.proto \
  -d @ \
  127.0.0.1:50051 \
  cc.arduino.cli.commands.v1.ArduinoCoreService.Monitor

Paste the open port request and press Enter:

{
  "openRequest": {
    "instance": { "id": 1 },
    "fqbn": "esp32:esp32:esp32da",
    "port": {
      "address": "/dev/cu.usbserial-0001",
      "protocol": "serial"
    },
    "portConfiguration": {
      "settings": [
        { "settingId": "baudrate", "value": "115200" }
      ]
    }
  }
}

The monitor pushes the responses to the terminal:

{
  "success": true
}
{
  "rxData": "AGV0cyBKdWwgMjkgMjAxOSAxMjoyMTo0Ng0KDSqSLKQSHMGohDgmIAMIoeAf+Q=="
}
{
  "rxData": "AAA="
}
{
  "rxData": "AAA="
}
{
  "rxData": "AAAAAA=="
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAA"
}
// filtered chunks...
{
  "rxData": "AAAA"
}
{
  "rxData": "AAA="
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAA"
}

Paste the baudrate change request to the terminal and press Enter:

{
  "updatedConfiguration": {
    "settings": [
      {
        "settingId": "baudrate",
        "value": "9600"
      }
    ]
  }
}{
  "rxData": "AAA="
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAAAA=="
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAAAA=="
}
{
  "rxData": "AAA="
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAAAA=="
}
{
  "rxData": "AAA="
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAA="
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAA"
}
{
  "rxData": "AAAA"
}
{
  "rxData": "Gw=="
}
{
  "rxData": "Ww=="
}
{
  "rxData": "Mw=="
}
{
  "rxData": "MQ=="
}
{
  "rxData": "bQ=="
}
{
  "rxData": "SA=="
}
{
  "rxData": "YQ=="
}
{
  "rxData": "bA=="
}
{
  "rxData": "bA=="
}
{
  "rxData": "bw=="
}
{
  "rxData": "Gw=="
}
{
  "rxData": "Ww=="
}
// filtered chunks...
{
  "rxData": "bA=="
}
{
  "rxData": "bw=="
}
{
  "rxData": "Gw=="
}
{
  "rxData": "Ww=="
}
{
  "rxData": "MA=="
}
{
  "rxData": "bQ=="
}
{
  "rxData": "IA=="
}
{
  "rxData": "Mg=="
}

The received data has changed after changing the baudrate, but there was no applied_settings response sent by the server.

This proves that the monitor starts to produce the expected output after switching to the correct 9600 baudrate:

"bA=="        → l  
"bG8bWzA="    → lo\x1b[0  
"bQ=="        → m  
"IA=="        →   (space)  
"MQ=="        → 1  
"DQ=="        → \r (carriage return)  
"Cg=="        → \n (newline)  
"Gw=="        → \x1b (ESC)  
"Ww=="        → [  
"Mw=="        → 3  
"Mw=="        → 3  
"bQ=="        → m  
"SA=="        → H  
"YQ=="        → a  
"bA=="        → l  
"bA=="        → l  
"bw=="        → o  
"Gw=="        → \x1b (ESC)  
"Ww=="        → [  
"MA=="        → 0  
"bQ=="        → m  
"IA=="        →   (space)  
"Mg=="        → 2  
"DQ=="        → \r  
"Cg=="        → \n  

The generated struct is not called from the codebase:

arduino-cli/rpc/cc/arduino/cli/commands/v1/monitor.pb.go

Lines 326 to 331 in c41f5df

	type MonitorResponse_AppliedSettings struct {
	// Settings applied to the port, may be returned after a port is opened (to
	// report the default settings) or after a new port_configuration is sent
	// (to report the new settings applied).
	AppliedSettings *MonitorPortConfiguration `protobuf:"bytes,3,opt,name=applied_settings,json=appliedSettings,proto3,oneof"`
	}

Expected behavior

The client receives the applied settings response after updating the monitor config.

Pipedream: the applied settings response contains the applied settingIds and the new values.

Arduino CLI version

c41f5df

Operating system

macOS

Operating system version

15.5

Additional context

The sketch that was used for the testing:

unsigned long previousMillis;
unsigned int ansi = 1;
unsigned int clearCounter = 0;
const unsigned int CLEAR_COUNTER_MAX = 10;

void setup() {
  Serial.begin(9600);
}

void loop() {
  if (Serial.available() > 0) {
    while (Serial.available() > 0) {
      Serial.write(Serial.read());
      delay(10);
    }
  } else if (millis() - previousMillis >= 500) {
    if (clearCounter == CLEAR_COUNTER_MAX) {
      Serial.print("\x1b[2J\x1b[3J\x1b[;H");
      clearCounter = 0;
    }
    previousMillis = millis();
    Serial.print("\x1b[3");
    Serial.print(ansi);
    Serial.print("mHallo\x1b[0m ");
    Serial.println(clearCounter);
    ansi++;
    clearCounter++;
    if (ansi > 6) {
      ansi = 1;
    }
    if (clearCounter == CLEAR_COUNTER_MAX) {
      Serial.println("Clearing terminal in next tick...");
    }
  }
}

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the nightly build
• My report contains all necessary details