You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
LazyToolBox: drop _tools_by_old_id bucket + lock remove_tool_by_id
``test_list_credentials_with_missing_tool`` calls
``remove_tool_by_id`` and asserts the next ``get_tool`` returns
None. Verified locally that a concurrent in-flight HTTP-thread
``_load_tool_on_demand`` would register a fresh Tool in
``_tools_by_old_id[tool_id]`` *before* MainThread acquired the
lock; ``super().remove_tool_by_id`` calls
``self._tools_by_old_id[old_id].remove(tool)`` which removes the
single Tool MainThread had a reference to but leaves the sibling
Tool registered by the concurrent loader. The eager
``super().get_tool`` fall-through then resurrects it via
``rval.extend(self._tools_by_old_id[tool_id])``.
Two fixes (verified locally with
``./run_tests.sh -integration ... test_list_credentials_with_missing_tool``
under ``GALAXY_CONFIG_OVERRIDE_USE_LAZY_TOOLBOX=true``: passes):
- Wrap ``remove_tool_by_id`` in ``app._toolbox_lock`` so the
cleanup runs atomically against ``_load_tool_on_demand`` /
``_register_loaded_tool``.
- Drop the entire ``_tools_by_old_id[tool_id]`` bucket — even
with the lock, a load that completed *before* the lock was
acquired left a sibling Tool the eager fall-through could find.
0 commit comments