arduino-cli
arduino-cli copied to clipboard
arduino
Signal when the `board list watch` command has started via gRPC
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
- [X] I searched for previous requests in the issue tracker
- [X] I verified the feature was still missing when using the nightly build
- [X] My request contains all necessary details
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.
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
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?
did you read a
quitmessage 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
quitorendmessage when an install/uninstall action is perfomed.
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.