Skip to content

fix: Set the tool name when changed #1488

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

Jump to bottom
Merged
kevalmahajan merged 2 commits into from
Nov 21, 2025
Merged

fix: Set the tool name when changed #1488

kevalmahajan merged 2 commits into from
Nov 21, 2025

Conversation

@gabe-l-hart
Copy link
Contributor

@gabe-l-hart gabe-l-hart commented Nov 20, 2025

Closes: #1485

Branch: ToolNameUpdate-1485

Signed-off-by: Gabe Goodhart ghart@us.ibm.com

@gabe-l-hart
fix: Set the tool name when changed
d4cbc9c 
IBM#1485
Branch: ToolNameUpdate-1485

Signed-off-by: Gabe Goodhart <ghart@us.ibm.com>
@gabe-l-hart gabe-l-hart marked this pull request as draft November 20, 2025 18:13
@gabe-l-hart
Copy link
Contributor Author

gabe-l-hart commented Nov 20, 2025

Hold on this one, I'm not sure it actually fixes the issue

@gabe-l-hart
Copy link
Contributor Author

gabe-l-hart commented Nov 20, 2025

Ok, this doesn't actually fix the problem. I'm stuck here. If I print out tool.name before db.commit() it is correctly updated, but after db.refresh() the value has reverted back to the original value.

I did manually try explicitly setting tool.custom_name to ensure that a different update would take and it does. It also seems to cause tool.name to override to tool.custon_name.lower().replace(" ", "-"_) which might be a clue about why tool.name isn't taking.

@gabe-l-hart
fix: Also update custom_name if it matches name
966874f 
Further digging in db.py shows that `name` is actually a computed property
that is backed by the `_computed_name` field in the DB. The logic to
compute `custom_name` and `gateway_slug` automatically populates these
fields if not set in the initial payload, so on subsequent updates, these
values are set and act as an override to the value being set when `name`
gets updated.

The logic in this fix is potentially problematic if a user did explicitly
set the `custom_name` field to match `name` and for some reason wants to
update `name` but NOT `custom_name`. This would not actually make sense to
do, though, so I think this is fairly correct at the moment.

IBM#1485
Branch: ToolNameUpdate-1485

Signed-off-by: Gabe Goodhart <ghart@us.ibm.com>
@gabe-l-hart gabe-l-hart marked this pull request as ready for review November 20, 2025 19:02
@gabe-l-hart
Copy link
Contributor Author

gabe-l-hart commented Nov 20, 2025

Ok, sorted it out. It turns out that name is actually a computed field and that since custom_name is auto-set when not present in the initial tool creation, it essentially acts as an override in the DB. I've added an additional check to this PR that handles the case where name and custom_name match and the update changes name, but doesn't explicitly change custom_name.

@kevalmahajan kevalmahajan self-requested a review November 21, 2025 06:49
kevalmahajan
kevalmahajan approved these changes Nov 21, 2025
View reviewed changes
Copy link
Member

@kevalmahajan kevalmahajan left a comment

Choose a reason for hiding this comment

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

The tool name value is updated as expected.

@kevalmahajan kevalmahajan merged commit e61b340 into IBM:main Nov 21, 2025
44 checks passed
@gabe-l-hart gabe-l-hart deleted the ToolNameUpdate-1485 branch November 21, 2025 15:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@kevalmahajan kevalmahajan kevalmahajan approved these changes

@crivetimihai crivetimihai Awaiting requested review from crivetimihai crivetimihai is a code owner

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[Bug]: Tool name update silently fails

2 participants

@gabe-l-hart @kevalmahajan