Skip to content

Conversation

matiaszilli
Copy link

@matiaszilli matiaszilli commented Aug 1, 2025

Summary

This PR adds support for configuring terminationGracePeriodSeconds on all pod deployments in the n8n Helm chart (main, worker, and webhook). This enhancement allows users to customize the graceful termination period for n8n pods, ensuring workflows can complete properly before pod shutdowns.

Motivation

Currently, the n8n Helm chart uses Kubernetes' default terminationGracePeriodSeconds (30 seconds), which may not be sufficient for long-running (more than 30 seconds) n8n workflows that need time to complete gracefully.

Benefits

  • Graceful Workflow Completion - Prevents workflow interruption during pod restarts
  • Configurable Per Component - Different timeouts for main/worker/webhook pods
  • Backward Compatible - Maintains default behavior when not configured
  • Zero Downtime Deployments - Improves reliability during rolling updates

Summary by CodeRabbit

  • New Features
    • Configurable pod termination grace period for main, worker, and webhook components so users can control how long Kubernetes waits before forcefully stopping pods.
  • Chores
    • Helm chart defaults and documentation updated to include a 30-second termination grace period hint for main, worker, and webhook, improving shutdown control and clarity.

Copy link
Contributor

coderabbitai bot commented Aug 1, 2025

Walkthrough

Helm chart templates and values for n8n were updated to add a configurable terminationGracePeriodSeconds parameter for the main, worker, and webhook pod specs, with conditional inclusion in each deployment template based on the corresponding values entry.

Changes

Cohort / File(s) Change Summary
Helm Deployment Templates
charts/n8n/templates/deployment.yaml, charts/n8n/templates/deployment.worker.yaml, charts/n8n/templates/deployment.webhook.yaml
Added conditional inclusion of terminationGracePeriodSeconds in each pod spec, sourcing from .Values.<component>.terminationGracePeriodSeconds.
Helm Values Configuration
charts/n8n/values.yaml
Added terminationGracePeriodSeconds: 30 entries for main, worker, and webhook.
Documentation
README.md
Documented the Pod terminationGracePeriodSeconds setting (example/comment) for main, worker, and webhook.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~7 minutes

Tip

🔌 Remote MCP (Model Context Protocol) integration is now available!

Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats.

✨ Finishing Touches
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, Documentation and Community

  • Visit our Status Page to check the current availability of CodeRabbit.
  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

♻️ Duplicate comments (2)
charts/n8n/templates/deployment.worker.yaml (1)

133-135: Same 0-value bug as in main deployment – see comment in deployment.yaml.

charts/n8n/templates/deployment.webhook.yaml (1)

137-139: Same 0-value bug as in main deployment – see comment in deployment.yaml.

🧹 Nitpick comments (1)
charts/n8n/values.yaml (1)

269-271: Avoid hard-wiring the default and clarify nullable behaviour

  1. By declaring a literal 30 here you always emit terminationGracePeriodSeconds in the rendered manifest, even when the user does not intend to change the Kubernetes default (which is already 30 s).
  2. A user cannot set the grace period to 0 (immediate kill) or unset it completely via null because the default from this file will override their attempt in a values-override.yaml unless they also remember to delete the key.

Consider:

-terminationGracePeriodSeconds: 30
+# Leave unset by default. Helm templates already fallback to the K8s
+# default (30 s) if the key is missing.
+# terminationGracePeriodSeconds:

This keeps backward compatibility and makes “set/unset” semantics intuitive.

Also applies to: 457-459, 645-647

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d5a4b1e and 57c1a57.

📒 Files selected for processing (4)
  • charts/n8n/templates/deployment.webhook.yaml (1 hunks)
  • charts/n8n/templates/deployment.worker.yaml (1 hunks)
  • charts/n8n/templates/deployment.yaml (1 hunks)
  • charts/n8n/values.yaml (3 hunks)

@RoseSecurity
Copy link
Contributor

Great addition! Would you consider removing the default value for the grace period? Currently, users cannot completely unset the grace period by setting it to null because the default value from the values will override any attempt to override it in a values-override.yaml file unless the user also remembers to delete the key.

@matiaszilli
Copy link
Author

Great addition! Would you consider removing the default value for the grace period? Currently, users cannot completely unset the grace period by setting it to null because the default value from the values will override any attempt to override it in a values-override.yaml file unless the user also remembers to delete the key.

Hey @RoseSecurity! Thanks for the suggestion. If we don't passterminationGracePeriodSeconds, Kubernetes sets it to 30s by default, so I don't see what's the value of removing it. Maybe in case Kubernetes changes the default value at some point?
In case we want to remove it, I think it's better to keep it commented in the values file so that it's easier to find that the terminationGracePeriodSeconds can be set.

@matiaszilli
Copy link
Author

Hi @Vad1mo! Could you please have a look and approve it? 🙏🏻

@Vad1mo
Copy link
Member

Vad1mo commented Aug 22, 2025

Update readme with new value

@matiaszilli
Copy link
Author

Update readme with new value

Thanks for the reminder. I updated it.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (3)
README.md (3)

550-552: Document intent clearly for worker pods and avoid implying a hard default

Mirror the guidance used in the main section so operators know they can leave this unset to inherit Kubernetes’ default and only set it when needed for long-running jobs.

Apply this diff:

-  # Pod termination grace period in seconds
-  terminationGracePeriodSeconds: 30
+  # Pod termination grace period in seconds. Leave unset to use Kubernetes default (30s).
+  # terminationGracePeriodSeconds: 120  # example for long-running workers

Context note:

  • If the templates use a simple if .Values.worker.terminationGracePeriodSeconds, an explicit 0 would be treated as “false” and the field would be omitted. Prefer a presence check that still renders 0 if set (see snippet below).

Outside-this-range reference snippet (template idea):

{{- $v := .Values.worker.terminationGracePeriodSeconds -}}
{{- if (hasKey .Values.worker "terminationGracePeriodSeconds") and ne $v nil -}}
terminationGracePeriodSeconds: {{ $v }}
{{- end -}}

738-740: Keep webhook docs consistent and add a short operational hint

Stay consistent with main/worker docs and add a note that webhook handlers might need longer grace periods during rolling updates to drain in-flight requests.

Apply this diff:

-  # Pod termination grace period in seconds
-  terminationGracePeriodSeconds: 30
+  # Pod termination grace period in seconds. Leave unset to use Kubernetes default (30s).
+  # terminationGracePeriodSeconds: 90  # example: allow draining in-flight webhooks on rollout

Optional doc improvement (outside this range):

  • Add a short “Graceful shutdown tips” subsection near the Values section that mentions:
    • Consider aligning terminationGracePeriodSeconds with average/max workflow duration.
    • Use RollingUpdate with maxUnavailable: 0 for zero-downtime rollouts when increasing grace periods.
    • Combine with a preStop hook if you need custom drain logic.

Happy to draft the “Graceful shutdown tips” blurb if you want it included.


362-364: Prefer leaving terminationGracePeriodSeconds unset to inherit the Kubernetes default

The Helm chart templates already use

{{- if hasKey .Values.<component> "terminationGracePeriodSeconds" }}
  terminationGracePeriodSeconds: {{ .Values.<component>.terminationGracePeriodSeconds }}
{{- end }}

so an explicit 0 will be honored (immediate kill) and omitting the key falls back to Kubernetes’ 30 s default.

Action items:

• README.md (lines 362–364) – replace the hard-coded default with a commented-out example and note the fallback:

-  # Pod termination grace period in seconds
-  terminationGracePeriodSeconds: 30
+  # Pod termination grace period in seconds. Leave unset to use Kubernetes default (30 s).
+  # terminationGracePeriodSeconds: 60  # uncomment to override

• charts/n8n/values.yaml – the default is currently set to 30 in three places (main, webhook, worker). Comment these out so users can “unset” and fall back to 30 s:

-  # Pod termination grace period in seconds
-  terminationGracePeriodSeconds: 30
+  # Pod termination grace period in seconds. Leave unset to use Kubernetes default (30 s).
+  # terminationGracePeriodSeconds: 30  # uncomment to override

Apply this change in each section around lines ~270 (main), ~458 (webhook), and ~646 (worker).

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

  • MCP integration is disabled by default for public repositories
  • Jira integration is disabled by default for public repositories
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between c79f0b4 and 9103fca.

📒 Files selected for processing (1)
  • README.md (3 hunks)

@matiaszilli
Copy link
Author

Hi @Vad1mo! Could you please help me to get it merged? 🙏🏻

1 similar comment
@matiaszilli
Copy link
Author

Hi @Vad1mo! Could you please help me to get it merged? 🙏🏻

@matiaszilli matiaszilli requested a review from Vad1mo September 29, 2025 11:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants