HYPERFLEET-430 | fix: formalize the executor log to help on debugging and tracking #24
Conversation
WalkthroughChanges convert executor logging to a phase-oriented model: phases (ParamExtraction, Preconditions, Resources, Post Actions, Finalization) now emit phase-qualified RUNNING/SUCCESS/FAILED/NOT_MET messages and concise phase-level summaries. Per-item index-based logs were replaced with name-based logs or consolidated phase summaries. Resource execution now computes an explicit operation (Skip/Create/Update/Recreate) with an OperationReason and centralizes operation decision and execution. Precondition and post-action code switched many Info logs to Debug and adjusted error formatting to include Sequence Diagram(s)(omitted) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
Comment |
xueli181114
force-pushed
the
HYPERFLEET-430
branch
from
3b883ef to
8627b2a
Compare
xueli181114
force-pushed
the
HYPERFLEET-430
branch
from
8627b2a to
79bf801
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
internal/executor/resource_executor.go (1)
153-159: Consider splitting long log lines for readability.The detailed logging is excellent for debugging, but the lines exceed typical length guidelines. Consider formatting the log arguments across multiple lines for better maintainability.
🔎 Optional formatting improvement
- re.log.Errorf(ctx, "Resource[%s] processed: FAILED - operation=%s reason=%s kind=%s name=%s error=%v", - resource.Name, result.Operation, result.OperationReason, gvk.Kind, manifest.GetName(), err) + re.log.Errorf(ctx, + "Resource[%s] processed: FAILED - operation=%s reason=%s kind=%s name=%s error=%v", + resource.Name, result.Operation, result.OperationReason, gvk.Kind, manifest.GetName(), err)- re.log.Infof(ctx, "Resource[%s] processed: SUCCESS - operation=%s reason=%s kind=%s name=%s", - resource.Name, result.Operation, result.OperationReason, gvk.Kind, manifest.GetName()) + re.log.Infof(ctx, + "Resource[%s] processed: SUCCESS - operation=%s reason=%s kind=%s name=%s", + resource.Name, result.Operation, result.OperationReason, gvk.Kind, manifest.GetName())
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
internal/executor/executor.gointernal/executor/post_action_executor.gointernal/executor/precondition_executor.gointernal/executor/resource_executor.gointernal/executor/types.go
🚧 Files skipped from review as they are similar to previous changes (2)
- internal/executor/post_action_executor.go
- internal/executor/types.go
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: xueli181114
Repo: openshift-hyperfleet/hyperfleet-adapter PR: 13
File: internal/executor/post_action_executor.go:198-205
Timestamp: 2025-12-04T14:06:51.656Z
Learning: Logger refactor is tracked in HYPERFLEET-304 for the hyperfleet-adapter repository, which will address how CEL evaluation failures and similar errors are handled and logged.
🧬 Code graph analysis (1)
internal/executor/executor.go (1)
internal/executor/types.go (3)
PhaseResources(25-25)PhasePostActions(27-27)StatusFailed(37-37)
🔇 Additional comments (8)
internal/executor/executor.go (2)
91-127: LGTM! Phase-oriented logging enhances observability.The phase-qualified logs (RUNNING, SUCCESS, FAILED, NOT_MET) provide clear execution flow and debugging context. The distinction between phase execution success and business outcomes (MET vs. NOT_MET) is well-handled.
131-167: LGTM! Resource and post-action phase logging is consistent.The phase-driven logging pattern is uniformly applied to resource and post-action phases, including proper handling of skipped resources and comprehensive error context.
internal/executor/resource_executor.go (3)
6-6: LGTM! Name-based iteration and logging improve clarity.The shift from index-based to name-based iteration and logging makes debugging easier by using meaningful resource identifiers throughout the execution flow.
Also applies to: 42-42, 76-76
95-98: LGTM! Appropriate log level adjustment.Moving discovery logs to Debug level reduces noise while maintaining visibility when detailed troubleshooting is needed.
101-143: LGTM! Operation decision logic is well-structured.The refactored decision logic cleanly separates operation determination from execution. The generation-based change detection with
OperationReasonprovides clear audit trails for debugging. The switch statement improves maintainability and makes the execution flow explicit.internal/executor/precondition_executor.go (3)
35-61: LGTM! Name-based precondition logging improves traceability.The refactored iteration and logging using precondition names rather than indices makes debugging clearer. The
formatConditionDetailshelper provides structured failure reasons that enhance observability.
86-86: LGTM! Appropriate log level adjustments for API call details.Moving API call implementation details to Debug level reduces noise in standard operations while keeping detailed traces available for troubleshooting.
Also applies to: 126-126, 153-153
171-171: LGTM! Well-balanced log level adjustments for conditions.The log level changes appropriately distinguish between implementation details (Debug) and business outcomes (Info). Keeping NOT_MET conditions at Info level ensures visibility for operational issues while reducing noise from successful evaluations.
Also applies to: 187-187, 189-189, 201-201, 211-211, 217-217
xueli181114
force-pushed
the
HYPERFLEET-430
branch
from
79bf801 to
d0b77f4
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
internal/executor/executor.go (2)
110-110: Redundanterror=in wrapped error message.The format
"precondition evaluation failed: error=%w"will produce messages like:
"precondition evaluation failed: error=<actual error>".This is inconsistent with other wrapped errors in the file (lines 138, 162) which don't include
error=in the format string. Theerror=prefix should only appear in log statements, not in error wrapping.🔎 Suggested fix
- precondErr := fmt.Errorf("precondition evaluation failed: error=%w", precondOutcome.Error) + precondErr := fmt.Errorf("precondition evaluation failed: %w", precondOutcome.Error)
238-258: Inconsistenterror=placement in error wrapping.The
error=prefix infmt.Errorfcalls (lines 238, 244, 251, 257) creates error messages like:
"failed to marshal map data: error=<actual error>"This is inconsistent with Go error wrapping conventions where
%wnaturally chains errors. Theerror=prefix should be reserved for log output, not embedded in error messages.However, if this is intentional per logging spec to ensure
error=appears in all error contexts, please confirm this is the desired behavior.🔎 Suggested fix (if not intentional)
- return nil, nil, fmt.Errorf("failed to marshal map data: error=%w", err) + return nil, nil, fmt.Errorf("failed to marshal map data: %w", err)- return nil, nil, fmt.Errorf("failed to marshal data: error=%w", err) + return nil, nil, fmt.Errorf("failed to marshal data: %w", err)- return nil, nil, fmt.Errorf("failed to unmarshal to EventData: error=%w", err) + return nil, nil, fmt.Errorf("failed to unmarshal to EventData: %w", err)- return nil, nil, fmt.Errorf("failed to unmarshal to map: error=%w", err) + return nil, nil, fmt.Errorf("failed to unmarshal to map: %w", err)internal/executor/resource_executor.go (1)
143-143: Minor: Trailing whitespace after switch block.Line 143 appears to have trailing whitespace. Consider removing for consistency.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
internal/executor/executor.gointernal/executor/post_action_executor.gointernal/executor/precondition_executor.gointernal/executor/resource_executor.gointernal/executor/types.go
🚧 Files skipped from review as they are similar to previous changes (1)
- internal/executor/types.go
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: xueli181114
Repo: openshift-hyperfleet/hyperfleet-adapter PR: 13
File: internal/executor/post_action_executor.go:198-205
Timestamp: 2025-12-04T14:06:51.656Z
Learning: Logger refactor is tracked in HYPERFLEET-304 for the hyperfleet-adapter repository, which will address how CEL evaluation failures and similar errors are handled and logged.
📚 Learning: 2025-12-04T14:06:51.656Z
Learnt from: xueli181114
Repo: openshift-hyperfleet/hyperfleet-adapter PR: 13
File: internal/executor/post_action_executor.go:198-205
Timestamp: 2025-12-04T14:06:51.656Z
Learning: Logger refactor is tracked in HYPERFLEET-304 for the hyperfleet-adapter repository, which will address how CEL evaluation failures and similar errors are handled and logged.
Applied to files:
internal/executor/post_action_executor.go
🧬 Code graph analysis (3)
internal/executor/resource_executor.go (2)
internal/executor/types.go (6)
OperationRecreate(155-155)OperationUpdate(153-153)OperationCreate(151-151)OperationSkip(157-157)NewExecutorError(375-382)PhaseResources(25-25)internal/config_loader/types.go (1)
Resource(229-234)
internal/executor/executor.go (2)
internal/config_loader/types.go (1)
AdapterConfig(59-64)internal/executor/types.go (4)
StatusFailed(37-37)PhaseResources(25-25)PhasePostActions(27-27)EventData(48-54)
internal/executor/post_action_executor.go (1)
internal/config_loader/types.go (1)
APICall(161-169)
🔇 Additional comments (18)
internal/executor/post_action_executor.go (2)
55-72: LGTM! Logging changes align with phase-based pattern.The switch from index-based to name-based logging (
PostAction[%s]) improves readability and debugging. Theerror=andstatus=prefixes are consistent with the logging specification as discussed in past reviews.
218-222: LGTM! API call logging appropriately moved to Debug level.Downgrading API call start/finish logs from
InfoftoDebugfreduces log noise while still providing visibility when debug logging is enabled.internal/executor/executor.go (5)
58-64: LGTM! Parse error handling with phase context.The error is properly logged with
error=prefix and the phase is correctly set toPhaseParamExtraction.
91-99: LGTM! Phase RUNNING log for parameter extraction.Clear phase start indication that aids in debugging and tracking execution flow.
103-127: LGTM! Preconditions phase logging with detailed outcomes.The logging distinguishes between:
FAILED(execution error)SUCCESS - NOT_MET(business condition not satisfied)SUCCESS - MET(all conditions passed)This provides good visibility into precondition evaluation outcomes.
131-148: LGTM! Resources phase logging.Clear phase transitions with configured count and outcome status (SUCCESS/SKIPPED/FAILED).
151-167: LGTM! Post actions phase logging.Properly handles the case where
Postconfig may be nil when determining action count. Phase transitions are consistent with other phases.internal/executor/resource_executor.go (5)
42-52: LGTM! Simplified iteration pattern.The switch from index-based to range-based iteration is cleaner and aligns with the broader logging refactor.
76-76: LGTM! Manifest built log provides useful context.The log includes resource name, kind, name, and namespace - all essential for debugging.
94-98: LGTM! Discovery outcome logging.Debug-level logs for discovery results are appropriate - they provide detail when needed without cluttering normal output.
101-142: LGTM! Centralized operation decision logic.The refactored code clearly:
- Determines the operation (Skip/Create/Update/Recreate) with reasons
- Logs the decision before execution
- Executes via a switch statement
This is easier to follow than inline decision/execution and improves debuggability.
153-159: LGTM! Consistent success/failure logging.Error and success logs follow the established pattern with operation, reason, kind, and name context.
internal/executor/precondition_executor.go (6)
35-61: LGTM! Precondition evaluation logging.The logging clearly distinguishes between:
FAILED- execution/API errorsNOT_MET- business condition not satisfied with detailsMET- condition passedThe
formatConditionDetailshelper provides useful context for NOT_MET cases.
86-86: LGTM! API call logging downgraded to Debug.Consistent with the same change in post_action_executor.go.
126-153: LGTM! Field capture logging at Debug level.Appropriate verbosity for field capture details while maintaining visibility when needed.
170-191: LGTM! Structured condition evaluation logging.The differentiation between matched (Debug) and not-matched (Info) conditions is appropriate - only non-matching conditions are surfaced at Info level for visibility.
199-218: LGTM! CEL expression evaluation logging.Debug-level logging for CEL expression and results is appropriate. The auto-match case for no conditions is also correctly logged at Debug level.
236-256: LGTM! Well-implemented helper function.
formatConditionDetailshandles:
- CEL errors
- Unmatched structured conditions with field/operator/expected/actual values
- Empty case with fallback message
Good defensive coding with the "no specific details available" fallback.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 86254860 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-merge-bot
bot
merged commit a5be140
into
openshift-hyperfleet:main
2 participants
Summary by CodeRabbit
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.