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

Đã đóng
  • Có gì không ổn?
#87 5 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
67/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
git, shell
Lĩnh vực
cli, devtools

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Shell
Star
16
Fork
6
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của DimitriGeelen/agentic-engineering-framework

Tất cả issue của DimitriGeelen/agentic-engineering-framework

Issue tương tự

Thêm issue về Shell/Bash

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.