Repository navigation
fix(add): stage a refresh until its setup is about to run - #246
Merged
Merged
Conversation
A source that could not be reached left the installed copy to run, and that held for a source the user named with --from too. A mistyped `--from` on an installed integration printed a note and ran the old copy's setup, while the test says it is an error before anything runs. That test passed only because a refused refresh before it had left another package's setup in the registry (#242), so the installed copy no longer matched its record and was refused off a terminal. It now runs first, on an intact install. The fallback stays for the sources funes picks itself: the catalog and $FUNES_INTEGRATIONS. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A refreshing `funes add` or `funes update` copied the incoming integration straight into ~/.funes/agents/<id>/ before the trust prompt. Declined, the rollback put back manifest.json alone: the rejected setup and hook scripts stayed where the agent's hooks run them, under a manifest naming the old release. provision now stages the files in a temporary directory and only reads the registry. Provisioned::install copies them in, opens the integration there and records it, and add, update, bind and remove call it right before setup runs. So any run that stops short of setup (trust declined, a memory that does not resolve, a first index declined) leaves the registry as it was, and restore_manifest and the fresh-install discard go. The trust prompt still names the directory setup will run from. Fixes #242. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With the refresh staged, `funes update` compared only the source's files with the record, so a hook edited or deleted in ~/.funes/agents stayed as it was and the update said "up to date". On main, provisioning had rewritten those files from the source before that check. The update now also verifies the installed copy. When the source hands it the recorded files but the installed copy changed, it installs them again and re-runs setup, unasked: those files were confirmed once. Found by Codex's review of #246. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A refreshing
funes addorfunes updatenow stages the incoming integration outside~/.funes/agentsand only installs it right beforesetupruns. Before, declining the trust prompt left the rejectedsetupand hooks in the live directory, under the old manifest, where the agent's hooks run them.Fixing it showed that
add --fromwith a bad path only failed in the test because of those leftovers. On an intact install it ran the old copy. So a source named with--fromthat can't be read is now an error, in its own commit.Found by Copilot in the review of #241. Fixes #242.
🤖 Generated with Claude Code