Rr/stacks/actions sro #37934
Draft
Rr/stacks/actions sro #37934
+4,917
−1,018
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Changelog WarningCurrently this PR would target a v1.15 release. Please add a changelog entry for in the .changes/v1.15 folder, or discuss which release you'd like to target with your reviewer. If you believe this change does not need a changelog entry, please add the 'no-changelog-needed' label. |
…call the hook in terraform_hook
…ation status messages
- Transfer Component.ActionInvocations to plan.Changes.ActionInvocations in ForModulesRuntime() - Populate plan.ActionTargetAddrs with action invocations - Skip action invocations when config lacks action trigger definitions
Add ReportConfigValue hook to support progressive emission of config values during stack operations. This enables reporting configuration values at different phases (pre-apply, post-apply) as they become available during graph traversal. - Add ReportConfigValue hook definition in stackeval hooks - Add ConfigValueHookData struct with addr, value, component, and phase - Support progressive resolution pattern for configuration values
Add ConfigValue message to StackChangeProgress to support streaming configuration values during stack operations. This enables clients to receive progressive updates about config values as they become available. - Add ConfigValue message with addr, phase, and available fields - Regenerate protobuf files with new message definition - Enable RPC streaming of config value availability updates
Wire up the config value hook to the RPC layer to stream configuration value updates to clients. This completes the RPC integration for progressive config value emission. - Add ReportConfigValue handler in stackChangeHooks - Convert hook data to StackChangeProgress_ConfigValue messages - Add comprehensive logging for config value RPC transmission - Enable real-time streaming of config value availability
Add progressive config value emission to component apply lifecycle. Config values are emitted at two key phases: after PENDING status (pre-apply) and after successful apply (post-apply). - Add emitKnownConfigValues function for extracting component outputs - Integrate config value emission after PendingComponentInstanceApply - Add post-apply emission before EndComponentInstanceApply - Support progressive resolution with pre-apply and post-apply phases - Add comprehensive logging for debugging and verification - Enable config value tracking throughout component lifecycle
Fix panic where emitKnownConfigValues was calling ResultValue() during apply phase, which requires a planning evaluator but apply uses an apply evaluator. The panic occurred because: - ResultValue() -> ModuleTreePlan() -> CheckModuleTreePlan() - CheckModuleTreePlan() expects planning evaluator - During apply, evaluator is set up for applying, not planning Solution: - Pre-apply phase: Use unknown values as placeholders instead of calling ResultValue() during apply operations - Post-apply phase: Only extract from final state, fallback to unknown values rather than calling ResultValue() This approach is safer and more appropriate for apply context where we should work with state rather than re-evaluating planning results.
Add robust error handling and defensive checks to prevent config value emission from causing apply failures: - Add panic recovery at multiple levels (function, hook invocation, callers) - Add null checks for hooks, component instances, and module trees - Skip emission when no outputs are declared to avoid unnecessary work - Add detailed logging to track emission process and debug issues - Wrap hook invocations with error recovery to isolate failures This ensures config value emission is non-blocking and provides better debugging visibility when issues occur during the apply process.
- Enable pre-apply config value emission in ApplyComponentPlan - Implement actual expression evaluation for pre-apply phase in emitKnownConfigValues - Pre-apply phase now attempts to resolve output values that depend only on: * Input variables * Local values * Data sources * Static configuration values - Post-apply phase remains disabled for safety until value access is better understood - Add comprehensive test coverage for both phases and defensive behavior - All existing functionality preserved with comprehensive error handling This implements true progressive resolution where config values become available at different phases of the apply process, starting with the pre-apply phase for values that can be resolved early.
…hase This commit implements Phase 1 of progressive config value resolution, enabling emission of configuration values during graph traversal as they become available. Key changes: - Added moduleExpressionScope to properly resolve var.* references to component input variables when evaluating Terraform module output expressions - Enhanced emitKnownConfigValues to attempt pre-apply evaluation of output expressions that depend only on inputs, locals, and data sources - Added moduleVariableReference to provide component input values for module variable resolution - Created comprehensive test coverage including real component evaluation - Added proper error handling and defensive programming with panic recovery The implementation enables users to see config values being emitted during terraform stacks execution as values become progressively available, improving visibility into the execution process. Progressive resolution flow: 1. Pre-apply phase attempts to evaluate output expressions using current known values 2. Module-level expression scope resolves var.marker to component inputs 3. Successfully evaluated values are emitted via ReportConfigValue hook 4. Post-apply phase disabled for safety (future enhancement) Test demonstrates successful evaluation of var.marker -> "a" during pre-apply phase.
RonRicardo
force-pushed
the
rr/stacks/actions-sro
branch
from
1d0ae23 to
7edb786
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #
Target Release
1.15.x
Rollback Plan
Changes to Security Controls
Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.
CHANGELOG entry