Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MsgPack encoding issue after upgrading to v0.5.0 #133

Closed
alexsomesan opened this issue Jan 4, 2022 · 4 comments · Fixed by #136
Closed

MsgPack encoding issue after upgrading to v0.5.0 #133

alexsomesan opened this issue Jan 4, 2022 · 4 comments · Fixed by #136
Assignees
Labels
bug Something isn't working
Milestone

Comments

@alexsomesan
Copy link
Member

terraform-plugin-go version

v0.5.0

Relevant provider source code

// insert code here

Terraform Configuration Files

# insert config here

Expected Behavior

Provider should work the same as with versions of terraform-plugin-go prior to v0.5.0

Actual Behavior

Error: ["manifest"]: msgpack: invalid code=84 decoding array length

Steps to Reproduce

Build the Kuberentes provider from the update-sdk branch and setup dev overrides for the binary.

Run terraform plan in any of the examples for the kubernetes_manifest resource.

The issue arises in the Terraform process on the return path from PlanResourceChange when decoding the response value. The issue is present even if no manipulation of the proposed plan is done in the provider (simply looping back the proposed plan).

References

@bflad
Copy link
Contributor

bflad commented Jan 4, 2022

Thanks for filing this, @alexsomesan! This certainly feels like a regression. Just noting that #107 would definitely help with troubleshooting here.

If I recall from before the end of year break, we saw that msgpack code 84 represents a fixmap (if I'm understanding correctly, with 2 objects) according to the specification. Since manifest is a tftypes.DynamicPseudoType, there could be some oddities with that type of data due to its special implementation. Off the cuff, It could be something like the types used to create values are mismatched somehow.

Is spinning up a bare bones EKS cluster good enough for executing those examples or is there further testing setup necessary?

@bflad bflad added this to the v0.6.0 milestone Jan 6, 2022
@bflad bflad self-assigned this Jan 6, 2022
@bflad
Copy link
Contributor

bflad commented Jan 6, 2022

@alexsomesan if you could give #135 a try with the TF_LOG_SDK_PROTO_DATA_DIR environment variable set and show the msgpack2json output from the relevant PlanResourceChange request and responses, that would be amazing. Thank you. 😄

bflad added a commit that referenced this issue Jan 7, 2022
Reference: #94
Reference: #99
Reference: #100
Reference: #128
Reference: #133

Reverts incorrect logic for handling DynamicPseudoType values in `tftypes`. This type information must be preserved when traversing the protocol, as Terraform CLI decodes values based on the schema information. If a concrete value type is used where DynamicPseudoType is expected, Terraform CLI will return errors such as (given an object of 4 attributes, when DynamicPseudoType is expected):

```
│ Error: ["manifest"]: msgpack: invalid code=84 decoding array length
```
bflad added a commit that referenced this issue Jan 13, 2022
Reference: #94
Reference: #99
Reference: #100
Reference: #128
Reference: #133

Reverts incorrect logic for handling DynamicPseudoType values in `tftypes`. This type information must be preserved when traversing the protocol, as Terraform CLI decodes values based on the schema information. If a concrete value type is used where DynamicPseudoType is expected, Terraform CLI will return errors such as (given an object of 4 attributes, when DynamicPseudoType is expected):

```
│ Error: ["manifest"]: msgpack: invalid code=84 decoding array length
```
@bflad
Copy link
Contributor

bflad commented Jan 18, 2022

v0.6.0 was just released 👍

Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants