Intermittent n8n Webhook Trigger Error: 'Cannot read properties of undefined (reading "node")'

Below is an analysis of the problem based on your description:

Issue Overview

You’re seeing an intermittent error message:

Cannot read properties of undefined (reading 'node')

This error originates deep in the job processing (specifically in the Bull queue library used by n8n) and is triggered when the webhook is executed. In about 0.7% of executions, the webhook trigger starts processing but then fails because a property expected on a node is missing (i.e. undefined).

What It Means

• Intermittent Behavior: Since the error only appears in a very small fraction of calls, it suggests that under certain conditions the internal object passed to the queue doesn’t have the expected structure.
• Queue/Job Processing: The stack trace points to the Bull queue job handler trying to access a property called “node” on an object that for some reason isn’t defined. This isn’t caused by an issue with the tool triggering the webhook, as you confirmed its payload seems correct.
• Data Receipt and Downstream Nodes: You mention that while the webhook trigger interface doesn’t reflect data, the downstream Slack node still receives an object. This could indicate that the error affects only part of the internal processing/recording or logging rather than the actual delivery of the payload.

Possible Contributing Factors

While this error isn’t covered directly in the common issues documentation, similar topics in the docs hint at areas to check:

• Workflow and Node Configuration:
  Although not exactly the same as the “stuck waiting for trigger event” or “bad webhook” issues seen with other trigger nodes, it’s worth verifying that all nodes in your workflow are configured as expected and that the webhook is set up correctly.

• Reverse Proxy or Network Conditions:
  If you’re running n8n behind a reverse proxy, some intermittent network discrepancies or misconfigurations (for example, not correctly enabling websocket support) can sometimes lead to unexpected internal behaviors. While the documented reverse proxy issues usually cause different errors (like “bad webhook: An HTTPS URL must be provided for webhook”), it’s useful to double-check your proxy settings.

• Resource Constraints or Memory Issues:
  Although your error doesn’t explicitly say it’s a memory problem, intermittent errors in queue processing can sometimes be triggered by temporary resource constraints. In self-hosted environments, monitoring resource usage (and possibly increasing available memory) may help rule out such scenarios.

Recommended Next Steps

1. Review Workflow Configuration:
   Check your webhook trigger and downstream nodes to ensure that all expected properties are present and that there’s no custom code or configuration (in any Code or Function node) that might sometimes produce an unexpected output.

2. Examine Network/Reverse Proxy Settings:
   If you operate n8n behind a reverse proxy (even in AWS Fargate setups), verify that your configuration (including any websocket support settings) fully complies with n8n’s reverse proxy recommendations.

3. Monitor Resource Usage:
   Since intermittent, low-frequency errors can stem from temporary resource saturation, monitor the CPU/memory usage on your instance. Ensure that the node process has enough headroom to process requests without issues.

4. Enable Additional Logging:
   Consider enabling more detailed logging around the webhook trigger event to capture further context when the error occurs. This may help pinpoint whether the incoming payload ever deviates from the expected structure.

5. File an Issue if Persistent:
   If after reviewing your configuration and environment the problem continues, consider reaching out via the n8n community or GitHub issues. Include the detailed error payload and conditions under which it occurs to help the maintainers investigate further.

Conclusion

The error “Cannot read properties of undefined (reading 'node')” is generated when an expected property on a processing object is missing in the internal queue handling for your webhook trigger. Although it affects only a small percentage of executions, it’s advisable to review both your workflow’s node configuration and your deployment’s network or resource settings. If you’re unable to find a misconfiguration, it might be worth filing an issue with additional details so the development team can investigate possible edge-case race conditions or bugs in the queue processing.

I hope this helps narrow down where the issue might be coming from!