Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug]: fw upgrade from a consumer refuses its own shallow auto-clone; the remedy names a directory deleted on exit

Chiusa
  • Qualcosa non va?
#87 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
67/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
git, shell
Ambito
cli, devtools

Direzione di ricerca

Start in lib/upgrade.sh at the bare-from-consumer auto-clone path around lines 1302–1313, then trace the origin guard and its refusal message. Reproduce by running fw upgrade in a consumer with an older recorded version_sha; check that the clone can verify that commit and that any printed remedy remains usable after exit. Done when the upgrade can proceed or the refusal gives an actionable remedy.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area:upgrade bug severity:high status:released triaged
Bug Description

fw upgrade run inside a vendored consumer project cannot succeed once upstream has moved past the consumer's recorded version_sha. Two parts of lib/upgrade.sh contradict each other:

  • The bare-from-consumer path always clones upstream with git clone --depth=1 (line 1313).
  • The origin guard then looks for the consumer's version_sha in that clone, cannot see it because the history is truncated, and refuses with foreign-source.

The remedy it prints, git -C /tmp/fw-upstream-XXXXXX/fw fetch --unshallow, then re-run fw upgrade, cannot be applied: that directory is removed when the process exits (trap "rm -rf '$_tmpd'" EXIT INT TERM HUP, line 1302), and re-running fw upgrade makes a new shallow clone in a new directory. The only path the message leaves open is the FW_ALLOW_FOREIGN_SOURCE=1 bypass.

The guard can pass only when the consumer is already at the tip, that is, when there is nothing to upgrade.

Steps to Reproduce
  1. Take a vendored consumer project whose .framework.yaml records a version_sha older than upstream master (here: 1.8.3, 542623a3, with upstream at 1.8.6).
  2. Run fw upgrade in it.

Observed twice on the same day, once by the agent and once by the operator from his own terminal.

Expected Behavior

fw upgrade fetches enough history to verify the consumer's commit and upgrades the project. If it must refuse, the remedy it prints can actually be followed.

Actual Behavior

Bare-from-consumer detected — auto-cloning upstream
Cloning... ok
Handing off to upstream's bin/fw: upgrade

Framework: /tmp/fw-upstream-XXXXXX/fw (v1.8.6)
Pinned: v1.8.3 (source does not contain this consumer's commit — upgrade will refuse)

REFUSED Consumer v1.8.3 vs framework v1.8.6: foreign-source.
consumer recorded version_sha 542623a3c914, which this SHALLOW clone (/tmp/fw-upstream-XXXXXX/fw) cannot see — its history is truncated, so origin is unverified, not disproved. Run: git -C /tmp/fw-upstream-XXXXXX/fw fetch --unshallow (or clone without --depth), then retry.
Remedy: git -C /tmp/fw-upstream-XXXXXX/fw fetch --unshallow, then re-run fw upgrade.
To proceed anyway: FW_ALLOW_FOREIGN_SOURCE=1 (logged Tier-2).

Exit code 1, nothing modified in the project. /tmp/fw-upstream-XXXXXX no longer exists when the message is read.

fw doctor output
AI Agent

Claude Code

Operating System

Linux

Additional Context

Version: consumer on 1.8.3 (542623a3), upstream 1.8.6 (1ea10441f). Line numbers are those of lib/upgrade.sh in 1.8.6.

Workaround that worked, without the bypass: a full clone made by hand, then the same hand-off the framework does itself:

git clone <upstream url> <dir>
env FRAMEWORK_ROOT=<dir> PROJECT_ROOT=<project> <dir>/bin/fw upgrade <project>

"28 change(s) applied", version 1.8.6. Without the two variables the cloned bin/fw resolves back to the project's vendored copy and starts the shallow auto-clone again.

Related remark: fw upgrade --dry-run from the consumer stops before cloning and prints only "would clone" and "would re-invoke" (line 1306). It lists none of the changes, so it cannot be used to preview an upgrade.

Suggestions:

  1. In the auto-clone path, fetch enough history for the guard: clone without --depth, or deepen the clone when the recorded version_sha is not found, before handing off.
  2. Do not print a remedy that names a directory the same process deletes on exit.
  3. Let --dry-run clone to the temporary directory so that it can list the changes.
Lingua principale
Shell
Stelle
16
Fork
6
Merge medio
6h 24m
PR unite (30g)
5

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DimitriGeelen/agentic-engineering-framework

Tutte le issue di DimitriGeelen/agentic-engineering-framework

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.