Signal when the board list watch command has started via gRPC

[kittaakos]

Describe the request

As a consumer of the gRPC API, I would like to receive an event if the gRPC equivalent of the board list watch command has started.

Currently, one can listen to the first BoardListWatchResponse event and consider the command running, but the first event might not ever arrive if the environment does have built-in ports (for example, COM1 on Windows, or /dev/cu.Bluetooth-Incoming-Port on macOS) although the command has successfully started and is running. A similar feature has been implemented for the monitor via 7afdc38.

Describe the current behavior

There is no explicit signaling if the gRPC equivalent of the board list watch has started.

Arduino CLI version

0.34.0

Operating system

macOS

Operating system version

13.5

Additional context

No response

Issue checklist

• I searched for previous requests in the issue tracker
• I verified the feature was still missing when using the nightly build
• My request contains all necessary details

[cmaglie]

What's the use case for this feature?

[kittaakos]

What's the use case for this feature?

See this 👇

but the first event might not ever arrive

A machine might want to know if the board list watch command is running. Imagine a standalone discovery service using the board list watch gRPC API. When you ask this discovery service, it should know its state and whether ready.

[kittaakos]

The CLI has a dedicated event type ('quit') to signal the end; why not add the 'start'?

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

Lines 199 to 200 in 3f9373a

	// Event type as received from the serial discovery tool
	string event_type = 1;

[cmaglie]

but the first event might not ever arrive

But even after the hypothetical started acknowledgment, you don't know when/if a port add event will arrive afterward.
The discoveries are asynchronous by nature, they don't have an "initial state"... I mean, even after discovery is started, it may require a few milliseconds for the initial messages to arrive.

That's the reason why the board list command has a --discovery-timeout argument: it's the amount of time to wait for discoveries to get data:

$ arduino-cli board list --discovery-timeout 0
No boards found.

$ arduino-cli board list --discovery-timeout 100ms
Port         Protocol Type              Board Name          FQBN                          Core               
/dev/ttyACM0 serial   Serial Port (USB) Arduino UNO R4 WiFi arduino:renesas_uno:unor4wifi arduino:renesas_uno
/dev/ttyS0   serial   Serial Port       Unknown                                                              

$ arduino-cli board list           # the default discovery timeout is 1s
Port         Protocol Type              Board Name          FQBN                          Core               
192.168.1.2  network  Network Port      Unknown                                                              
/dev/ttyACM0 serial   Serial Port (USB) Arduino UNO R4 WiFi arduino:renesas_uno:unor4wifi arduino:renesas_uno
/dev/ttyS0   serial   Serial Port       Unknown                                                              

As you can see the slowest discoveries take more time to provide port data, serial is fairly quick (<100ms) mdns-discovery may take even >1s to actually discover the board via network.

The CLI has a dedicated event type ('quit') to signal the end; why not add the 'start'?

Uhm... the quit message is used internally to unwire a single discovery from being broadcasted to the active watchers, did you read a quit message in the gRPC API?

[kittaakos]

did you read a quit message in the gRPC API?

arduino/arduino-ide@a8ae0bb#diff-535c5b57092ab0075afb79d52d75b187b361a4eed5e581be76a51de1500bf8fdR101-R105

From here arduino/arduino-ide#674 (comment):

The reason is that, in some circumstances that need to be further investigated, the CLI is not sending the quit or end message when an install/uninstall action is perfomed.

[cmaglie]

That comment refers to a very old implementation of the board watch, in fact, the same message says:

This is a workaround as the correct way to approach the issue should be on the CLI side: there is no reason why the business logic of stopping/restarting the boards watchers shoud be on the IDE.

And that's how I reimplemented the watcher, I'm pretty sure no quit messages are incoming from the board watch gRPC API.

The IDE only sees a stream of add and remove events, it doesn't know if there were 1 or more discoveries under the hood. If a discovery is "removed", this is handled internally from the daemon, the IDE only sees a bunch of ports remove events.