service: Refactor connection build and service.collection field set#301
Conversation
Where that happens? |
Ah, forgot to mention that. When calling service method Lock, |
|
Can you get the backtrace? |
|
|
That is not the actual fix though. If you look at https://github.com/bilelmoussaoui/oo7/blob/main/server/src/service.rs#L308-L317 we do serve the Service as part of creating the connection, which means the methods can be called at that point of time, like Lock/Unlock although the connection is not yet set on the field. So the solution is to move the serve_at after setting the connection field. |
|
cc @A6GibKm as you did the changes causing this regression |
|
Yeah, understood. Thanks @bilelmoussaoui ! Will update the pr. |
This completes the service object initialization before serving it and avoids potential None returns when accessing the connection field through service method calls. See: linux-credentials#301 (comment)
|
Have you tested your changes ? does it work as expected now? |
Yes. No more, |
|
Note: this fix is not related to issues mentioned in #302 |
| .at( | ||
| oo7::dbus::api::Service::PATH.as_deref().unwrap(), | ||
| service.clone(), | ||
| ) |
There was a problem hiding this comment.
There is a difference in behaviour though, serve_at when called the moment of building the connection, will replace the existing instance of the served interface. Where ObjectServer::at doesn't. So basically the request_replacement no longer does what it is supposed to do.
There was a problem hiding this comment.
oh! I didn't know that, thanks! Let me double check on this.
| .serve_at( | ||
| oo7::dbus::api::Service::PATH.as_deref().unwrap(), | ||
| service.clone(), | ||
| )? |
There was a problem hiding this comment.
why is this not done above?
There was a problem hiding this comment.
Yeah.... I can do that :)
To restrict service methods from being called before setting the service.collection field, we set the service.collection along with the connection creation. With this approach we can still call serve_at. Fixes potential None returns when accessing service.collection
For some reason, even though the call to
Service.connection.set()succeeds, afterwards calls toService.connection.get()always return None.This fixes this issue.