Preserve canonical content when a custom-layout move fails

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

Maintainer thường phản hồi trong vòng 1 ngày

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

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
38/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
php
Lĩnh vực
backend, databases

Hướng nghiên cứu

Bắt đầu trong inc/class-wp-markdown-storage.php tại WP_Markdown_Storage::write_profile_post(), đặc biệt là chuỗi di chuyển custom-layout quanh các dòng 910-924. Theo dõi staging, việc publish đến đích, việc dọn dẹp đường dẫn cũ, lập chỉ mục đường dẫn và các receipt của đường dẫn đã thay đổi, sau đó bổ sung coverage lỗi xác định cho việc publish, dọn dẹp và thay thế thư mục. Hoàn tất khi các tiêu chí chấp nhận được đáp ứng mà không mất nội dung, không có bản trùng lặp và không có trạng thái cuối không nhất quán.

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

Mô tả

Problem

The custom content-layout move path stages the replacement, deletes the old canonical file, and only then renames the staged file into place. If the final rename fails, the old file has already been removed and the staged file is discarded, leaving no canonical copy.

Relevant implementation: WP_Markdown_Storage::write_profile_post() in inc/class-wp-markdown-storage.php, around lines 910-924.

This violates the canonical durability contract required by the database-independent engine in #232.

Required outcome

  • Make custom-layout moves recoverable across the old-path and new-path publication boundary.
  • Preserve at least one complete canonical copy when publication or cleanup fails.
  • Bind staging and commit to the same verified destination directory identity.
  • Keep path indexing and changed-path receipts consistent with the terminal filesystem state.
  • Add deterministic failure injection around destination publication and old-path cleanup.

Acceptance criteria

  • A failed destination rename leaves the original canonical post intact.
  • A successful move leaves exactly one canonical post at the selected route and removes the stale route.
  • Retry after an interrupted move converges without content loss or duplicate durable identities.
  • Directory replacement between staging and commit fails closed.

AI assistance

GPT-5.6 Sol via OpenCode reviewed the custom-layout publication sequence, identified the delete-before-publish failure mode, and helped structure this issue and its acceptance criteria. Chris Huber directed the review and issue creation.

Ngôn ngữ chính
PHP
Star
8
Fork
1
Merge trung bình
22 giờ 28 phút
Pull request đã merge (30 ngày)
15

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

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

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 Automattic/markdown-database-integration

Tất cả issue của Automattic/markdown-database-integration

Issue tương tự

Thêm issue về PHP

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.