Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

History log "committed" column is inaccurate

Đang mở
  • Có gì không ổn?
#1,237 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 4 ngày

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

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/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ệ
xml
Lĩnh vực
backend, cli

Hướng nghiên cứu

Bắt đầu với %IPM.General.AbstractHistory:Finalize() tại src/cls/IPM/General/AbstractHistory.cls:124 và lần theo các nhánh thiết lập giao dịch, phân giải chế độ nhà phát triển, commit và rollback trong %IPM.Utils.Module:LoadModuleFromDirectory() quanh các dòng 1137-1315. Tái hiện cả việc tải module.xml không đúng định dạng với -dev và việc cài đặt với -DNoTransaction=1; hoàn tất khi Committed khớp với việc các thay đổi có thực sự được giữ lại hay không.

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

Mô tả

bug

Describe the bug

The Committed column on history records does not reliably indicate whether an action's changes survived. It is computed from the action's status and whether developer mode was on, rather than from what actually happened to the transaction:

%IPM.General.AbstractHistory:Finalize() (src/cls/IPM/General/AbstractHistory.cls:124):

set ..Committed = (dev = 1) || $$$ISOK(status)

This is wrong in both directions.

Dev-mode failures are always marked committed, even when fully rolled back.

In %IPM.Utils.Module:LoadModuleFromDirectory(), the transaction opens at line 1160 and the first developer-mode tcommit is at line 1272. tDeveloperMode is not even resolved until line 1259. Everything in that window runs inside a transaction that the catch block rolls back at lines 1313-1315, regardless of developer mode.

So a -dev action that fails before line 1272 (for example a malformed module.xml rejected in GetModuleObjectFromPath) is rolled back in full, but its history record still reads Committed.

The intended dev-mode behavior for phases after line 1272 is correct and is not at issue here. The early-failure window is.

Non-transactional failures are marked uncommitted despite keeping their changes.

tUseTransactions is false when -DNoTransaction=1 or -DNoJournal=1 is passed (line 1137). No transaction is opened, so a failure leaves partial changes in the namespace. Because the status is an error and developer mode is off, the record reads Uncommitted.

To Reproduce

Rolled-back action reported as committed:

  1. load /path/to/malformed-module -dev where the directory contains a module.xml with a syntax error
  2. history find -limit 5
  3. The record shows an error in Success and Committed in Committed, even though the transaction was rolled back and nothing was written

Retained changes reported as uncommitted:

  1. install some-module -DNoTransaction=1 with a module whose Activate phase fails
  2. history find -limit 5
  3. The record reads Uncommitted, but partial changes remain in the namespace

Expected behavior

Committed should reflect whether the action's changes were actually retained.

Options, roughly in increasing order of effort:

  1. Compare $tlevel against the level captured at entry, or have the rollback path signal that it ran, and pass that to Finalize() instead of inferring from dev.
  2. Set Committed at each commit point rather than once at the end, so the flag tracks how far the action actually got.
  3. If the current value is intentional as a coarse signal, rename it or document it as "changes may have been retained" and stop treating dev = 1 as sufficient.

Option 1 is the smallest change that fixes both directions, since it makes the flag observed rather than derived.

System information

  • IPM version: 0.10.5+
Ngôn ngữ chính
ObjectScript
Star
41
Fork
29
Merge trung bình
4 ngày 8 giờ
Pull request đã merge (30 ngày)
8

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 intersystems/ipm

Tất cả issue của intersystems/ipm

Issue tương tự

Thêm issue về Backend & API Design

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.