Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#87 5 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
67/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
git, shell
Área
cli, devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Shell
Estrellas
16
Forks
6
Merge medio
6 h 24 min
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de DimitriGeelen/agentic-engineering-framework

Todos los issues de DimitriGeelen/agentic-engineering-framework

Issues similares

Más issues de Shell/Bash

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.