Connection::open_path can fails if there are no remove CIDs for the path. There is nothing the application can do about this, it normally resolves itself after a little while once CIDs arrive.
However the application is never told when new CIDs are available. Iroh currently works around this by waiting some arbitrary (long) time before trying again, which is not ideal.
If we added a PathEvent::NewCids { path_id: PathId } then it would be possible for the application to react and try again.
One challenge is that new CIDs often come in batches, but that the application only needs the event once per batch. This problem already exists with the events emitted by Connection::nat_traversal_updates. Another issue with the batches is that the events queue is bounded, so if a lot of new CIDs arrive other events in the queue will be pushed out. So it is kind of important to debounce on the emitting side. Or maybe events are the wrong mechanism for this entirely.
A watcher-style API might be an option. But needing to have each path ID means it needs to be a set or similar, and collections are not very suitable for watchers. If it is a watcher it might have to be expressed as the set of all paths which currently have CIDs, or something similar.
Connection::open_pathcan fails if there are no remove CIDs for the path. There is nothing the application can do about this, it normally resolves itself after a little while once CIDs arrive.However the application is never told when new CIDs are available. Iroh currently works around this by waiting some arbitrary (long) time before trying again, which is not ideal.
If we added a
PathEvent::NewCids { path_id: PathId }then it would be possible for the application to react and try again.One challenge is that new CIDs often come in batches, but that the application only needs the event once per batch. This problem already exists with the events emitted by
Connection::nat_traversal_updates. Another issue with the batches is that the events queue is bounded, so if a lot of new CIDs arrive other events in the queue will be pushed out. So it is kind of important to debounce on the emitting side. Or maybe events are the wrong mechanism for this entirely.A watcher-style API might be an option. But needing to have each path ID means it needs to be a set or similar, and collections are not very suitable for watchers. If it is a watcher it might have to be expressed as the set of all paths which currently have CIDs, or something similar.