Variable substitution results in validation error: cannot convert int64 to string

[reitermarkus]

Describe the bug

I have a secret which gets generated as

stringData:
  TELEGRAM_CHAT_ID: ${telegram_chat_id}

where telegram_chat_id is a number represented as a string, e.g. defined in a cluster-vars secret as

stringData:
  telegram_chat_id: "123456789"

yet when this is generated, it produces a number, i.e.

stringData:
  TELEGRAM_CHAT_ID: 123456789

resulting in a

validation error: cannot convert int64 to string

when trying to deploy this secret.

It does not matter whether the interpolated value is quoted as '${telegram_chat_id}' or "${telegram_chat_id}", the secret is always generated as an unquoted number.

Steps to reproduce

Create a secret by a interpolating a value containing a number.

Expected behavior

Don't change the value type to a number and correctly generate the secret with

stringData:
  telegram_chat_id: "123456789"

Screenshots and recordings

No response

OS / Distro

macOS 12.6.3

Flux version

2.0.1

Flux check

► checking prerequisites ✔ Kubernetes 1.27.3 >=1.24.0-0 ► checking controllers ✔ helm-controller: deployment ready ► ghcr.io/fluxcd/helm-controller:v0.35.0 ✔ kustomize-controller: deployment ready ► ghcr.io/fluxcd/kustomize-controller:v1.0.1 ✔ notification-controller: deployment ready ► ghcr.io/fluxcd/notification-controller:v1.0.0 ✔ source-controller: deployment ready ► ghcr.io/fluxcd/source-controller:v1.0.1 ► checking crds ✔ alerts.notification.toolkit.fluxcd.io/v1beta2 ✔ buckets.source.toolkit.fluxcd.io/v1beta2 ✔ gitrepositories.source.toolkit.fluxcd.io/v1 ✔ helmcharts.source.toolkit.fluxcd.io/v1beta2 ✔ helmreleases.helm.toolkit.fluxcd.io/v2beta1 ✔ helmrepositories.source.toolkit.fluxcd.io/v1beta2 ✔ kustomizations.kustomize.toolkit.fluxcd.io/v1 ✔ ocirepositories.source.toolkit.fluxcd.io/v1beta2 ✔ providers.notification.toolkit.fluxcd.io/v1beta2 ✔ receivers.notification.toolkit.fluxcd.io/v1 ✔ all checks passed

Git provider

GitHub

Container Registry provider

No response

Additional context

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[reitermarkus]

I found this ugly workaround in the meantime:

stringData:
  TELEGRAM_CHAT_ID: ${double_quote:="}${telegram_chat_id}${double_quote:="}

[kingdonb]

That is horrible, but I like it because you figured out another workaround that I haven't seen yet. (Most of the old ones don't work anymore.)

But someone else figured out (they read the YAML spec, which says) that you can prevent quoted strings from becoming something else when they are parsed and reparsed by putting a type tag, or hint, reference from the spec here (2.4. Tags):

stringData:
  TELEGRAM_CHAT_ID: !!str "${telegram_chat_id}"

This should do it 🤞 I haven't tested this myself, but I've been given this info by another user who reported the solution in Slack about two weeks ago. I think this is the proper right way to solve it! Please let us know if it works.

[reitermarkus]

No, this doesn't work it seems.

[reitermarkus]

For the fun of it, I also tried

stringData:
  TELEGRAM_CHAT_ID: "!!str ${telegram_chat_id}"

which, according to flux build output, actually correctly quotes the string as

stringData:
  TELEGRAM_CHAT_ID: '!!str ${telegram_chat_id}'

and when deployed the secret correctly contains !!str 123456789.

[kingdonb]

That's right... the example they provided was actually this one:

  postBuild:
    substitute:
      aws_account_id: "!!str 23123213123"

I guess that's not what's in the YAML spec, but it should work.

I'm guessing it would work, except for you're doing it in a postbuild substitution in a kustomize generator.

(Can you provide the complete example? It takes a bit of time to reproduce the situation, and I'm sure it's some combination of factors that won't be easy to come by without making up some details, for example please provide the kustomization files and show how you are engaging the postbuild substitution and any generator configs that you mentioned in the top post)

I am sure the problem has to do with the order of the parsing of the YAML along with the building and the substitution. If the YAML spec says to put the tag outside of the quotes, I wouldn't put it inside the quotes, (I don't think this matters however as I mentioned the person who reported this workaround two weeks ago put their tags inside the quotes.) They didn't say anything about a substitution though. I guess that is the confounding factor. I don't know any way to solve this.

[kingdonb]

Just another idea, have you tried omitting the quotes entirely? (Only use the !!str tag)

[reitermarkus]

Nope, no quotes also doesn't work.

[kevinvalk]

This got me thinking and I think the best solution is to place the !!str tag inside the variable to be substituted like variable: "!!str 01234"

I just tested this and it worked wonderful. As far as I can reason about this, the trick is that the tag !!str and the number should be somewhere at the "same time" after substitution. So I guess it would even work to do something like (UNTESTED):

stringData:
  TELEGRAM_CHAT_ID: ${str_tag:=!!str}${telegram_chat_id}

But I think it is nicer to just have the telegram_chat_id variable be "!!str 123456789" (NOTE the quotes before !!str to delay the YAML tag until AFTER the variable substitution).

P.S. Maybe this can be documented in variable substitution docs?