Propagate gateway timeouts to dashboard deployment

[welteki]

Description

Propagates three gateway timeout environment variables to the dashboard deployment in the Helm chart:

• upstream_timeout - so the dashboard can compare each function's exec_timeout against the gateway's upstream timeout and show a warning when the function timeout exceeds it.
• read_timeout and write_timeout - these must match the gateway's values for dashboard invocations to work correctly. If the dashboard's timeouts are shorter, it can close the connection before the gateway completes the request.

Why is this needed?

• I have raised an issue to propose this change (required)

The upstream_timeout is required for the gateway timeout warning feature added to the dashboard. The read_timeout and write_timeout were not correctly propagated to the dashboard, which could cause the dashboard to close connections prematurely before the gateway finished handling a request.

Who is this for?

What company is this for? Are you listed in the ADOPTERS.md file?

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have signed-off my commits with git commit -s
• I have added tests to cover my changes.
• All new and existing tests passed.

[reviewfn]

AI Pull Request Overview

Disclaimer: This review was generated by automated AI and may contain errors. Do not trust its outputs without human verification.

Summary

• The PR adds upstream_timeout, read_timeout, and write_timeout environment variables to the dashboard deployment.
• The values are sourced from the same gateway Helm values already used by the gateway deployment.
• The scoped diff contains one chart template change and no Go code changes.
• I found no concrete correctness, compatibility, or security issues in the scoped change.

Approval rating (1-10)

9/10. The change is narrowly scoped and consistent with existing chart configuration; only local Helm rendering could not be performed in this environment.

Summary per file

Summary per file

File path	Summary
chart/openfaas/templates/dashboard-dep.yaml	Propagates gateway timeout settings into the dashboard container environment.

Overall Assessment

The scoped change is low risk. The added dashboard environment variables use existing Helm values with established defaults in values.yaml and match the environment variable names already set for the gateway. I do not see a specific failure mode introduced by this PR.

Detailed Review

Detailed Review

No blocking findings.

The added variables in chart/openfaas/templates/dashboard-dep.yaml are consistent with the existing gateway deployment template:

Dashboard variable	Source value	Existing gateway variable
upstream_timeout	.Values.gateway.upstreamTimeout	upstream_timeout
read_timeout	.Values.gateway.readTimeout	read_timeout
write_timeout	.Values.gateway.writeTimeout	write_timeout

The default values are present under gateway in chart/openfaas/values.yaml, so the dashboard deployment should not receive empty values under the standard chart configuration.

AI agent details.

Agent processing time: 3m45.188s
Environment preparation time: 1m2.847s
Total time from webhook: 6m40.87s