search

arduino / arduino-cli

Arduino command line tool
https://arduino.github.io/arduino-cli/latest/
GNU General Public License v3.0
4.32k stars 373 forks source link

Signal when the `board list watch` command has started via gRPC #2284

Open kittaakos opened 1 year ago

kittaakos commented 1 year ago

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 https://github.com/arduino/arduino-cli/commit/7afdc383289531a3755578f4a92248fa35b7cb18.

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

cmaglie commented 1 year ago

What's the use case for this feature?

kittaakos commented 1 year ago

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 commented 1 year ago

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

https://github.com/arduino/arduino-cli/blob/3f9373a14698c9c1cffd30b519b1f81a12433a58/rpc/cc/arduino/cli/commands/v1/board.proto#L199-L200

cmaglie commented 1 year ago

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 commented 1 year ago

did you read a quit message in the gRPC API?

https://github.com/arduino/arduino-ide/commit/a8ae0bb4e035d655c61fa68836795430ae9e080f#diff-535c5b57092ab0075afb79d52d75b187b361a4eed5e581be76a51de1500bf8fdR101-R105

From here https://github.com/arduino/arduino-ide/pull/674#issue-1076844060:

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 commented 1 year ago

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.