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

literal integer are interpreted as int instead of int64. #1143

Closed
ninoles opened this issue Sep 25, 2018 · 4 comments
Closed

literal integer are interpreted as int instead of int64. #1143

ninoles opened this issue Sep 25, 2018 · 4 comments
Assignees
Labels
Milestone

Comments

@ninoles
Copy link

ninoles commented Sep 25, 2018

Consul Template version

consul-template v0.19.5 (57b6c71)

Configuration

{{ scratch.Set "t" 2 }}
{{ range $x := loop (scratch.Get "t") }} -> {{ $x }}
{{ end }}

or even:

{{ $n := 2 }}
{{ range $x := loop $n }} -> {{ $x }}
{{ end }}

Command

consul-template -dry -once -template template.txt

Debug output

https://gist.github.com/ninoles/a8c20e7ce709e15e969350d205bd5c57

Expected behavior

What should have happened?

The template should have run the loop and print -> 1 -> 2

Actual behavior

.\template.txt: execute: template: :2:33: executing "" at <"t">: wrong type for value; expected int64; got int

Steps to reproduce

  1. run the command line as shown above.

References

@ninoles
Copy link
Author

ninoles commented Sep 25, 2018

An easy workaround is to do a scratch.Set "t" (parseInt "2") instead, which will correctly set the value save to a int64, but I can't see why either, loop can't use a int, or that all int should be considered int64.

@ninoles
Copy link
Author

ninoles commented Sep 25, 2018

I update the bug report with the same example using a simple variable this time... same results.

@ninoles ninoles changed the title Scratch Set literal value as int. literal integer are interpreted as int instead of int64. Sep 25, 2018
@eikenb eikenb added the bug label Jun 14, 2019
@eikenb eikenb added this to the 0.21.1 milestone Aug 7, 2019
@eikenb
Copy link
Contributor

eikenb commented Aug 7, 2019

Thanks for the report @hashicorp/consul-eco

I'm not sure why the original author changed loop to take int64 instead of int (which it did before that). There is no explanation nor linked issue and it was done 6 months after loop was added (back in 2015). Anyone have a clue?

@eikenb eikenb self-assigned this Aug 8, 2019
eikenb added a commit that referenced this issue Aug 9, 2019
`loop` when passed a scrach or $variable that contained an int as the
function was typed to only take int64. This changes it more like the
other functions that takes a interface{} and type switches/converts it
using reflect. Made it handle integer strings while I was at it.

Fixes #1143
@eikenb
Copy link
Contributor

eikenb commented Aug 9, 2019

Fix coming with PR #1255

eikenb added a commit that referenced this issue Aug 9, 2019
`loop` when passed a scrach or $variable that contained an int as the
function was typed to only take int64. This changes it more like the
other functions that takes a interface{} and type switches/converts it
using reflect. Made it handle integer strings while I was at it.

Fixes #1143
@eikenb eikenb closed this as completed in 94ded09 Aug 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants