rather than requiring users to supply a value, we probably want to leave 100 as a default while allowing users to override it, like we do for DBCONNECTOR_QUERY_TIMEOUT_MS here: https://github.com/tryretool/retool-helm/pull/247/files#diff-ce58e50773488bf13409091c468325d84396844ea7f7fff711b3c0933200e983R102-R109

That is a good suggestion. I will add a condition where if it is set in the values.yml, then it won't get set here.

@golfdish, I keep getting this error from the tests about "nil pointer evaluating interface {}.environmentVariables". Maybe there is a type issue that I am running into, or I need to approach this differently to check if the value is being set in ".Values.environmentVariables" or ".Values.env"

@taylormusolf I actually found a better example of how it could be done elsewhere:

this takes a config value from the dbconnector section. you could similarly make a variable for the pool size under the workflows config (currently empty) and reference it in the workflows templates, which would have the same effect of setting a changeable default.

@golfdish The problem I am running into is that this is used in all of the templates where it blanket applies the env and environmentVariables. Technically, the same double variable issue would happen in dbconnector as well if they were to both set the env variable and set the config variable. I am trying to apply that fixed variable only if the user doesn't use it in env or environmentVariables values. I mean I could create a new special variable in values.yml that only applies the variable to the retool-backend and have the customer only set that going forward and then leave everything else as it originally was.

@golfdish , I revised my approach and went off of your idea to just add a new variable to values.yaml. I left everything alone for workflows with the hardcoded values and instead created a new variable in the values.yaml config to be used similarly to the dbconnector config variable that is used for the standalone dbconnector setup, and that variable is being used in the deployment_backend template.

ah, I missed the wrinkle of possibly double-applying the config and env values. I feel like maybe that could be avoided on the user's end? but I'll trust the testing you've done. ooc, does the current change achieve your goal of raising the dbconnector pool max size for workflows?

@golfdish The issue was that they needed to apply it to the backend container, and they were trying to do that via setting it in the environmentVariables, but that led to the issue with it being double-applied in workflows since those variables get blanket added to all containers.