Fix environment variable parsing in get_integer function

[Fudster]

Fix environment variable parsing in get_integer function

Updated the get_integer function to properly convert the environment variable value to an integer instead of using the variable name. This change ensures the correct value is processed.

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

The application crashes during boot in Kubernetes environments with the following error:

ERROR! Config provider Config.Reader failed with:
** (ArgumentError) errors were found at the given arguments:
  * 1st argument: not a textual representation of an integer
    :erlang.binary_to_integer("PORT")
    /app/releases/2.46.2/runtime.exs:290: (file)
    (elixir 1.17.3) src/elixir.erl:386: :elixir.eval_external_handler/3
    (stdlib 6.1.2) erl_eval.erl:904: :erl_eval.do_apply/7
    (stdlib 6.1.2) erl_eval.erl:1192: :erl_eval.expr_list/7
    (stdlib 6.1.2) erl_eval.erl:446: :erl_eval.expr/6
    (stdlib 6.1.2) erl_eval.erl:436: :erl_eval.expr/6
    (stdlib 6.1.2) erl_eval.erl:437: :erl_eval.expr/6
Runtime terminating during boot ({badarg,[{erlang,binary_to_integer,[<<"PORT">>],[{error_info,#{module=>erl_erts_errors}}]},{elixir_eval,'__FILE__',1,[{file,"/app/releases/2.46.2/runtime.exs"},{line,290}]},{elixir,eval_external_handler,3,[{file,"src/elixir.erl"},{line,386}]},{erl_eval,do_apply,7,[{file,"erl_eval.erl"},{line,904}]},{erl_eval,expr_list,7,[{file,"erl_eval.erl"},{line,1192}]},{erl_eval,expr,6,[{file,"erl_eval.erl"},{line,446}]},{erl_eval,expr,6,[{file,"erl_eval.erl"},{line,436}]},{erl_eval,expr,6,[{file,"erl_eval.erl"},{line,437}]}]})
Crash dump is being written to: erl_crash.dump...done

The issue occurs because String.to_integer(env) was being called with the environment variable name "PORT" instead of its actual value. This causes binary_to_integer to fail when trying to convert the literal string "PORT" to an integer.

What is the new behavior?

The get_integer function now correctly calls String.to_integer(value) where value contains the actual environment variable value (e.g., "4000") rather than the variable name. This allows the application to boot successfully in Kubernetes environments.

Additional context

This bug only manifested in Kubernetes deployments and was not reproducible in Docker environments, likely due to differences in how environment variables are handled or set between the two container orchestration platforms. I forgot to rebuild the image, so the bug also appears locally on Docker too. The fix ensures consistent behavior across all deployment environments.

Update: Also discovered and fixed another related bug with GENERATE_CLUSTER_CERTS environment variable handling. The script was failing with "unbound variable" error when this optional variable wasn't defined. I didn't notice this before because I had it defined in Kubernetes and didn't rebuild the Docker image locally. Fixed by using bash parameter expansion ${GENERATE_CLUSTER_CERTS:-} to handle the optional variable gracefully.

[vercel]

@Fudster is attempting to deploy a commit to the Supabase Team on Vercel.

A member of the Team first needs to authorize it.

[h0lybyte]

Amazing, LFG!

[Fudster]

Just discovered another related bug while testing this fix! 🐛

The script was also failing with:

/app/run.sh: line 93: GENERATE_CLUSTER_CERTS: unbound variable

This was happening because the script tries to check ${GENERATE_CLUSTER_CERTS} but the variable wasn't defined. I didn't notice this before because I had it set in my Kubernetes deployment and never rebuilt the Docker image locally to test.

Fixed it by using bash parameter expansion:

# Before
if [[ -n "${GENERATE_CLUSTER_CERTS}" ]] ; then

# After  
if [[ -n "${GENERATE_CLUSTER_CERTS:-}" ]] ; then

The :- syntax provides an empty string default when the variable is unset, preventing the "unbound variable" error while maintaining the same logic flow.

[filipecabaco]

ended up implementing the fixes in #1520 to guarantee all workflows would work

[Fudster]

ended up implementing the fixes in #1520 to guarantee all workflows would work

Disappointed this wasn't approved due to a flawed(?) review process. I had other work planned but reconsidering now, I was going to work on the handle_out issue with the external ID, but not sure anymore.

[filipecabaco]

I understand the frustration and it's kind of shitty at the moment ... let me actually check with the team how we can improve it as it's not very contribution friendly.

mainly two points that we need to revise:

• the fact that there's always a need to bump up mix.exs makes it very user unfriendly
• the logic of feat vs fix vs chore branch names are needed to move to the right version

let me check with the team if we are able to have quick wins that improve this

[Fudster]

I understand the frustration and it's kind of shitty at the moment ... let me actually check with the team how we can improve it as it's not very contribution friendly.

mainly two points that we need to revise:

* the fact that there's always a need to bump up mix.exs makes it very user unfriendly

* the logic of feat vs fix vs chore branch names are needed to move to the right version

let me check with the team if we are able to have quick wins that improve this

Valid points. A couple of potential solutions:

For the mix.exs bumping:
A GitHub Action could handle version bumping automatically, eliminating the manual step. Could be a manual action that you trigger when ready to release (useful for batching multiple PRs together).

For conventional commits:
You could use squash merges and handle the proper commit format at merge time rather than requiring contributors to get it perfect upfront. This gives contributors flexibility while keeping your commit history clean.

[filipecabaco]

will share this solution with team

[Fudster]

Oops, that's me working on GitHub Actions and other stuff. In the future, I'll be pushing from a clean feature branch that I won't force push to (lol)