Skip to content

RSDK-11067: remove resource on alwaysrebuild #458

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
lia-viam merged 5 commits into from
Jul 1, 2025
Merged

RSDK-11067: remove resource on alwaysrebuild #458

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
5f4dcdc
remove resource on alwaysrebuild
lia-viam Jun 27, 2025
9185837
use resource name
lia-viam Jun 30, 2025
769e664
fix call to reg lookup
lia-viam Jul 1, 2025
2332592
remove rsdk comment
lia-viam Jul 1, 2025
b5578ce
error on model reg not found
lia-viam Jul 1, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 3 additions & 5 deletions src/viam/sdk/module/service.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -128,16 +128,14 @@ struct ModuleService::ServiceImpl : viam::module::v1::ModuleService::Service {
stoppable->stop();
}

manager->remove(cfg.resource_name());

const std::shared_ptr<const ModelRegistration> reg =
Registry::get().lookup_model(cfg.name());
Registry::get().lookup_model(cfg.api(), cfg.model());
Copy link
Member

@acmorrow acmorrow Jul 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you fail to look up the model registration here, I think you should return an error. It's a pretty strange state of affairs because the model was registered once, apparently, such that the object could be brought into existence (otherwise, what is being reconfigured?) but now that it is time to reconfigure by rebuilding, the registration is gone. That also would have made the error here obvious, rather than a silent misbehavior.

Copy link
Collaborator Author

@lia-viam lia-viam Jul 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're right, it was really confusing to debug


// TODO RSDK-11067 new resource gets constructed while old one is still alive.
if (reg) {
try {
const std::shared_ptr<Resource> resource = reg->construct_resource(deps, cfg);
manager->replace_one(cfg.resource_name(), resource);
std::shared_ptr<Resource> resource = reg->construct_resource(deps, cfg);
manager->replace_one(cfg.resource_name(), std::move(resource));
Copy link
Member

@acmorrow acmorrow Jul 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Arguably, this is part of RSDK-11067, but the behavior here means that if construct_resource fails, the old one sticks around. Is that OK?
  • Maybe add some warn logging here after the call to replace_one that if res.use_count != 1 that the old Resource has been held alive somewhere? I know it isn't perfect due to multithreading, but at least it gives some indication that things haven't gone according to plan.

Copy link
Member

@acmorrow acmorrow Jul 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, I just saw the commit that removed the TODO RSDK-11067, but this review doesn't fix that fully. The call to construct_resource here happens before the call to replace_one which will (in theory) remove the old one. If the intention is to actually resolve RSDK-11067, the ordering here needs to be changed, and I don't think replace_one can be used.

Copy link
Collaborator Author

@lia-viam lia-viam Jul 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this does resolve RSDK-11067 at least in terms of the observed behavior. Maybe the issue title was described incorrectly, because it would be more accurate to say that in the absence of Reconfigurable the reconfiguration was not happening whatsoever, the old one was not getting deleted, etc.

If we do it without replace_one would you suggest a manual call to remove followed by add ? Because it occurred to me that in the absence of Reconfigurable that a call to ReconfigureResource should be equivalent to RemoveResource followed by AddResource, so maybe we can reuse the code from each of those

} catch (const std::exception& exc) {
return grpc::Status(::grpc::INTERNAL, exc.what());
}
Expand Down
5 changes: 3 additions & 2 deletions src/viam/sdk/resource/resource_manager.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,6 +108,7 @@ void ResourceManager::do_remove(const Name& name) {
ErrorCondition::k_resource_not_found,
"Attempted to remove resource " + name.to_string() + " but it didn't exist!");
}

resources_.erase(short_name);

std::string const shortcut = get_shortcut_name(short_name);
Expand Down Expand Up @@ -135,8 +136,8 @@ void ResourceManager::remove(const Name& name) {
do_remove(name);
} catch (std::exception& exc) {
VIAM_SDK_LOG(error) << "unable to remove resource: " << exc.what();
};
};
}
}

void ResourceManager::replace_one(const Name& name, std::shared_ptr<Resource> resource) {
const std::lock_guard<std::mutex> lock(lock_);
Expand Down
Loading