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

Reading binary file using file::read in bolt plan, causes apply blocks to fail. #3334

Open
benjamin-robertson opened this issue Jul 3, 2024 · 1 comment
Labels
Bug Bug reports and fixes.

Comments

@benjamin-robertson
Copy link

Describe the Bug

Reading a binary file into a string using file::read within a bolt plan causes apply blocks to fail.

I am able to use the write_file function to write the binary file out to systems and this works as expected.

Expected Behavior

Apply blocks should still function even if a binary file is read into a string variable.

Steps to Reproduce

Steps to reproduce the behavior:

Read binary file into a string.

$test_file = file::read('/usr/bin/vim')

Attempt to use an apply block in the same plan. You don't need to use this variable in the apply block. Its existence within the plan is enough to cause it to fail.

  $apply_results = apply($linux_targets) {
    file { '/tmp/test':
      ensure => file,
    }

When the plan is run, the apply blocks will fail with the following message.

Failed on ip-10-64-194-133.ap-southeast-2.compute.internal:
  Apply failed to compile for ip-10-64-194-133.ap-southeast-2.compute.internal: source sequence is illegal/malformed utf-8

Environment

  • Bolt 3.30
  • Ubuntu 22.04

Additional Context

I'm assuming this is occurring as local variables from the plan are accessible within the apply block. When transforming the value for the apply block its expecting utf8. https://dev.to/bajena/solving-invalid-byte-sequence-in-utf-8-errors-in-ruby-1f27

@benjamin-robertson benjamin-robertson added the Bug Bug reports and fixes. label Jul 3, 2024
@donoghuc
Copy link
Member

donoghuc commented Jul 3, 2024

Thanks for the report. Yeah variables in plan scope need to be serialized to json to be passed to the compile process. My guess is that something along the way is choking on that. From a quick glance it looks like our data converter is being invoked with rich_data option

plan_vars = Puppet::Pops::Serialization::ToDataConverter.convert(plan_vars,
but i'm not sure exactly where in the stack that is blowing up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Bug reports and fixes.
Projects
None yet
Development

No branches or pull requests

2 participants