Shopware cart.expire_days cannot be set through environment variables

[mromeike]

Shopware Version

6.5.8.12

Affected area / extension

Platform(Default)

Actual behaviour

The configuration does not support the use of env-vars to define the expiry of neither shopware.cart.expire_days nor shopware.sales_channel_context.expire_days.

This hinders quick changes to these critical values and especially for PaaS will always require a code-change and re-deployment.

Expected behaviour

The env-var is accepted as value at compile time and only evaluated at runtime.

How to reproduce

Take the following configuration:

parameters:
  env(CART_EXPIRE_DAYS): 10

shopware:
  cart:
    expire_days: '%env(int:CART_EXPIRE_DAYS)%'

To reproduce the error below:

www-data@a671b715b4ff:~/html$ bin/console debug:config shopware cart
Symfony\Component\Config\Definition\Exception\InvalidConfigurationException^ {#27774
  #message: "The value 0 is too small for path "shopware.cart.expire_days". Should be greater than or equal to 1"
  #code: 0
  #file: "./vendor/symfony/config/Definition/NumericNode.php"
  #line: 45
  -path: "shopware.cart.expire_days"
  -containsHints: false
  trace: {
    ./vendor/symfony/config/Definition/NumericNode.php:45 { …}
    ./vendor/symfony/config/Definition/BaseNode.php:421 { …}
    ./vendor/symfony/config/Definition/BaseNode.php:410 { …}
    ./vendor/symfony/config/Definition/ArrayNode.php:252 { …}
    ./vendor/symfony/config/Definition/BaseNode.php:421 { …}
    ./vendor/symfony/config/Definition/ArrayNode.php:252 { …}
    ./vendor/symfony/config/Definition/BaseNode.php:421 { …}
    ./vendor/symfony/config/Definition/Processor.php:36 { …}
    ./vendor/symfony/config/Definition/Processor.php:46 { …}
    ./vendor/symfony/dependency-injection/Compiler/ValidateEnvPlaceholdersPass.php:77 { …}
    ./vendor/symfony/dependency-injection/Compiler/Compiler.php:80 { …}
    ./vendor/symfony/dependency-injection/ContainerBuilder.php:767 { …}
    ./vendor/symfony/http-kernel/Kernel.php:507 { …}
    ./vendor/shopware/core/Kernel.php:193 { …}
    ./bin/console:54 {
      {closure}^
      › $application = new Application($kernel);
      › $kernel->boot();
      › 
    }
    ./vendor/symfony/runtime/Resolver/DebugClosureResolver.php:25 { …}
    ./vendor/autoload_runtime.php:24 { …}
    ./bin/console:17 { …}
  }
}

This is caused by a comparison of the env-var default value 0 (zero) to the compile-time constraints defined for the bundle configuration.

---

Based on the code I also suspect that the following options do not support this as well:

• shopware.sitemap.batchsize
• shopware.dal.batch_size
• shopware.dal.max_rule_prices
• shopware.dal.versioning.expire_days
• shopware.cart.expire_days
• shopware.sales_channel_context.expire_days
• As well as all config nodes added in later versions with min($v) where $v > 0.
  In the latest version there are 15 usages of min() in the Configuration.php file of Shopware Core.

---

The cause for this lies with Symfony itself and how it compiles the DI container. Symfony generally does not support mixing runtime and compile time parameters.

See also symfony/symfony#58878 (comment).

This means either the constraints on the config node(s) are removed or the node(s) should explicitly be marked to not support placeholders.

[github-actions]

🚀 Shopware Issue Triage has started processing this issue

[github-actions]

AI Triage Result

Validated result from triage run 29321709239.

Field	Value
Disposition	valid-bug
Severity	medium
Confidence	0.88
Suggested labels	domain/framework, component/core
Duplicate of	None
Change size	small
Missing template fields	None
Related issues	None
Related PRs	None

Reasoning

Integer config nodes in src/Core/Framework/DependencyInjection/Configuration.php that use ->min(1) constraints (e.g. shopware.cart.expire_days, shopware.sales_channel_context.expire_days, and ~13 others) fail at container compile time when set to Symfony env-var placeholders, because Symfony's ValidateEnvPlaceholdersPass substitutes a placeholder value of 0 during compilation which violates the min(1) constraint. Confirmed via rg: the file at src/Core/Framework/DependencyInjection/Configuration.php contains multiple ->min(1) calls on integerNode definitions for all the listed paths. The #[Package('framework')] marker on line 18 confirms the domain/framework label. The fix requires either removing the min constraints from affected nodes or explicitly marking them to not accept env-var placeholders (via disallowNewKeysInSubsequentConfigs or similar Symfony mechanism). The reporter links to the upstream Symfony issue (symfony/symfony#58878). No related PRs or duplicate issues found.

Evidence

• [issue] "The value 0 is too small for path "shopware.cart.expire_days". Should be greater than or equal to 1" — InvalidConfigurationException from ValidateEnvPlaceholdersPass
• [issue] "This is caused by a comparison of the env-var default value 0 (zero) to the compile-time constraints defined for the bundle configuration."
• [shell] src/Core/Framework/DependencyInjection/Configuration.php — contains ->integerNode('expire_days')->min(1) at multiple locations (cart, dal versioning, sales_channel_context, deep_link)
• [shell] src/Core/Framework/DependencyInjection/Configuration.php line 18: #[Package('framework')]
• [issue] "In the latest version there are 15 usages of min() in the Configuration.php file of Shopware Core."

Affected paths

• src/Core/Framework/DependencyInjection/Configuration.php

Recent commits in area

None

triage-output.json

{
  "disposition": "valid-bug",
  "severity": "medium",
  "suggested_labels": ["domain/framework", "component/core"],
  "confidence": 0.88,
  "reasoning": "Integer config nodes in `src/Core/Framework/DependencyInjection/Configuration.php` that use `->min(1)` constraints (e.g. `shopware.cart.expire_days`, `shopware.sales_channel_context.expire_days`, and ~13 others) fail at container compile time when set to Symfony env-var placeholders, because Symfony's `ValidateEnvPlaceholdersPass` substitutes a placeholder value of 0 during compilation which violates the min(1) constraint. Confirmed via rg: the file at `src/Core/Framework/DependencyInjection/Configuration.php` contains multiple `->min(1)` calls on integerNode definitions for all the listed paths. The `#[Package('framework')]` marker on line 18 confirms the domain/framework label. The fix requires either removing the min constraints from affected nodes or explicitly marking them to not accept env-var placeholders (via `disallowNewKeysInSubsequentConfigs` or similar Symfony mechanism). The reporter links to the upstream Symfony issue (symfony/symfony#58878). No related PRs or duplicate issues found.",
  "evidence_quotes": [
    "[issue] \"The value 0 is too small for path \\\"shopware.cart.expire_days\\\". Should be greater than or equal to 1\" — InvalidConfigurationException from ValidateEnvPlaceholdersPass",
    "[issue] \"This is caused by a comparison of the env-var default value 0 (zero) to the compile-time constraints defined for the bundle configuration.\"",
    "[shell] src/Core/Framework/DependencyInjection/Configuration.php — contains `->integerNode('expire_days')->min(1)` at multiple locations (cart, dal versioning, sales_channel_context, deep_link)",
    "[shell] src/Core/Framework/DependencyInjection/Configuration.php line 18: `#[Package('framework')]`",
    "[issue] \"In the latest version there are 15 usages of min() in the Configuration.php file of Shopware Core.\""
  ],
  "duplicate_of": null,
  "missing_template_fields": [],
  "affected_paths": [
    "src/Core/Framework/DependencyInjection/Configuration.php"
  ],
  "related_issues": [],
  "related_prs": [],
  "recent_commits_in_area": [],
  "change_size_estimate": "small"
}

[keulinho]

Hey Marcel Romeike (@mromeike) ,

thanks for raising this issue, your analysis is completely correct, the symfony config validation currently prevents using env vars to configure those config options. However we decided to not change anything here, the validation serves a purpose and we rather keep that and not allow env vars for those config options, as during normal operations those values do not need to change often and likely it is ok when that requires a new deployment.

Setting them via env var is mostly useful during testing to fine tune the settings based on concrete usage, however when that fine tuning is done we do not expect that they are changed regularly.

As a workaround you can create a little compiler pass that reads your env var value and overrides the concrete service arguments with the value you pass over the env var when that is set.