Fix missing AttributePathExpression in plan modifier requests for top level attributes and blocks

[ChihweiLHBird]

Related Issue

Fixes #1258

Description

This PR fixes a bug where AttributePathExpression was missing in plan modifier requests for top-level attributes and blocks. The issue occurred in the SchemaModifyPlan function where ModifyAttributePlanRequest structs were created without populating the AttributePathExpression field.

Problem

When plan modifiers were called for top-level attributes and blocks, the PathExpression field in the request was empty, which could cause issues for plan modifiers that rely on this information for path-based operations.

Solution

• Added AttributePathExpression: path.MatchRoot(name) to both attribute and block request creation in SchemaModifyPlan
• Added a comprehensive test case "attribute-pathexpression" to verify the PathExpression is correctly populated
• Updated the test attribute to be Optional: true, Computed: true to better simulate real-world plan modifier usage

Changes

1. internal/fwserver/schema_plan_modification.go: Added missing AttributePathExpression field initialization
2. internal/fwserver/schema_plan_modification_test.go: Added new test case and updated attribute configuration

Testing

go test ./internal/fwserver/... -v

• All existing tests continue to pass
• New test verifies PathExpression is correctly set to path.MatchRoot("test") for top-level attributes
• Test uses optional/computed attribute to simulate typical plan modifier scenarios

[Copilot]

Pull request overview

This PR fixes a bug where the AttributePathExpression field was missing from plan modifier requests for top-level attributes and blocks in the SchemaModifyPlan function. The missing field caused issues for plan modifiers that rely on PathExpression for operations like path.MatchRelative(), as reported in issue #1258.

Changes:

• Added AttributePathExpression: path.MatchRoot(name) to ModifyAttributePlanRequest for both top-level attributes and blocks
• Added a comprehensive test case verifying that PathExpression is correctly populated for top-level attributes

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
internal/fwserver/schema_plan_modification.go	Added AttributePathExpression field initialization for top-level attributes (line 87) and blocks (line 145)
internal/fwserver/schema_plan_modification_test.go	Added new test case "attribute-pathexpression" to verify PathExpression is correctly set to path.MatchRoot("test") for top-level attributes

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

internal/fwserver/schema_plan_modification.go:146

• The schema-level block plan modifier requests are now populated with AttributePathExpression, but SchemaModifyPlan currently has no unit test coverage for top-level blocks. This risks regressions where block plan modifiers (e.g., planmodifier.Object) would again receive an empty PathExpression.

Consider adding a test case that defines a top-level block (e.g., testschema.BlockWithObjectPlanModifiers) with a testplanmodifier.Object that asserts req.PathExpression.Equal(path.MatchRoot("<block_name>"))).

	for name, block := range s.GetBlocks() {
		blockReq := ModifyAttributePlanRequest{
			AttributePath:           path.Root(name),
			AttributePathExpression: path.MatchRoot(name),
			Config:                  req.Config,