Adds addresses field to gettowerinfo
#151
Conversation
|
Notice this is a breaking change for the protos, given it modifies them without updating its version. I don't think it is worth a version bump for them at the moment, maybe when more functionality has been added (or after the next major update). |
|
Something I'd like to discuss here would be how to address proto updates without them being breaking changes. I haven't really paid much attention to this so far, and maybe we don't want to, but there are ways of making it backward compatible. https://developers.google.com/protocol-buffers/docs/proto3#updating |
sr-gi
force-pushed
the
gettowerinfo_addresses
branch
from
a3131f8 to
644be32
Compare
I've rebased this and made the change non-breaking. This was breaking due to the field order, and the only good reason for the ordering was having I've also moved the TL;DR: this is non-breaking now. |
teos/src/api/tor.rs
Outdated
| loop { | ||
| sleep(Duration::from_secs(1)).await; | ||
| if shutdown_signal_tor.is_triggered() { | ||
| break; | ||
| } | ||
| } |
There was a problem hiding this comment.
This can be replace with
shutdown_signal_tor.await;There was a problem hiding this comment.
Indeed, nice one! I never liked that chuck of code
sr-gi
force-pushed
the
gettowerinfo_addresses
branch
from
644be32 to
9ae985e
Compare
|
Should be good to go now |
sr-gi
force-pushed
the
gettowerinfo_addresses
branch
2 times, most recently
from
d23a5f9 to
8477075
Compare
teos/src/api/tor.rs
Outdated
|
|
||
| // // NOTE: Needed to keep connection with control port & hidden service running, as soon as we leave | ||
| // // this function the control port stream is dropped and the hidden service is killed | ||
| // loop { | ||
| // sleep(Duration::from_secs(1)).await; | ||
| // if shutdown_signal_tor.is_triggered() { | ||
| // break; | ||
| // } | ||
| // } |
There was a problem hiding this comment.
This is still here 😆
sr-gi
force-pushed
the
gettowerinfo_addresses
branch
from
8477075 to
0c1b4c1
Compare
This PR adds a new field to the
gettowerinfoRPC call. The field includes data regarding the interfaces where the public API is being offered (i.e. ipv4 and/or tor).The rationale for this is having the API endpoint information handy without having to check the logs (this is currently most relevant for the onion address).
Fixes #143
cc/ @jochemin