Skip to content

fix: update stale nested bundle URIs when reloaded from different source#83

Open
colombod wants to merge 1 commit intomicrosoft:mainfrom
colombod:fix/stale-nested-bundle-uris
Open

fix: update stale nested bundle URIs when reloaded from different source#83
colombod wants to merge 1 commit intomicrosoft:mainfrom
colombod:fix/stale-nested-bundle-uris

Conversation

@colombod
Copy link
Contributor

Summary

Fixes the persistent-state half of microsoft-amplifier/amplifier-support#62.

When a parent bundle (e.g., foundation) is overridden to a local path via settings.local.yaml, nested bundles previously persisted with git+ URIs kept their stale URIs indefinitely. This PR ensures registry entries are refreshed when a bundle is reloaded from a different source.

Root Cause

BundleRegistry._load_single() has an update block (lines 506–510) that refreshes version, loaded_at, and local_path for known bundles — but it did not update uri. Combined with persisted state loaded from registry.json on init, this meant:

  1. First session (no overrides): nested bundles get git+ URIs → persisted to registry.json
  2. Second session (with local overrides): _load_single() reloads the nested bundle from a file:// URI, but the existing entry's uri field is never updated
  3. registry.json retains the stale git+ URI across all subsequent sessions

Change

+5 lines in amplifier_foundation/registry.py — surgical addition to the existing update block:

if update_name:
    state = self._registry[update_name]
    if state.uri != uri:                          # ← NEW
        logger.debug(                             # ← NEW
            f"Updating URI for '{update_name}': {state.uri}{uri}"
        )                                         # ← NEW
        state.uri = uri                           # ← NEW
    state.version = bundle.version
    state.loaded_at = datetime.now()
    state.local_path = str(local_path)

The URI is only updated when it actually differs, with a debug log for traceability. For same-URI reloads this is a no-op.

Evidence

Diff stats

  • amplifier_foundation/registry.py: +5 lines (production fix)
  • tests/test_registry.py: +164 lines (3 regression tests)

Test results

Suite Before After Delta
amplifier-foundation full suite 298 passed ✅ 301 passed ✅ +3 new, 0 regressions

New regression tests (TestNestedBundleURIUpdate)

Test What it verifies
test_persisted_nested_bundle_uri_updates_on_reload Pre-populated git+ URI in registry.json gets updated to file:// when the same bundle is loaded from a local path
test_persisted_uri_update_survives_save_reload Updated URI persists correctly across save() → new BundleRegistry cycle
test_same_uri_reload_does_not_change_entry Reloading from the same URI is a no-op (guards against unnecessary mutations)

Companion PR

This is the first of two PRs for issue #62. The companion PR in amplifier-app-cli changes get_bundle_categories() to read from the in-memory registry instead of stale registry.json on disk. This foundation PR should merge first (it fixes the persistent state that the CLI reads).

How to verify end-to-end

After both PRs merge:

  1. Add bundle.added.foundation: ../../amplifier-foundation to settings.local.yaml
  2. Run any Amplifier session (to trigger bundle loading with the override)
  3. Run amplifier bundle list --all
  4. Confirm nested bundles show file:// paths, not git+ GitHub URLs

When a parent bundle is overridden to a local path via settings.local.yaml,
nested bundles previously persisted with git+ URIs would keep their stale
URIs because _load_single() skipped re-registering existing entries.

Now the existing entry's URI and local_path are updated when the bundle
is reloaded from a different source, ensuring registry.json stays in sync
with actual source overrides.

Fixes: microsoft-amplifier/amplifier-support#62

🤖 Generated with [Amplifier](https://github.com/microsoft/amplifier)

Co-Authored-By: Amplifier <240397093+microsoft-amplifier@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

Comments