The messy input

SKU ,Product Name,Price,Qty,Updated
A-001, Blue Mug ,$4.50,12,2026/10/01
a-001,Blue Mug,4.5,12,01-10-2026
A-002,Green Mug,USD 4.75,,2026-10-02
A-003,red  plate,6,8,2026.10.03
,,,,
A-004,Tea Spoon (x4),$2.00 ,30,2026-10-04
A-005,Bowl,N/A,5,2026-10-05
A-003,Red Plate,6.00,8,2026-10-03
A-006,Napkin Pack,"1,25",100,Oct 6 2026

That's 9 data rows, not counting the header. Write that number down first.

Step 1: normalise before you dedupe

A-001 and a-001 look different, but they're the same row. So are the two A-003 rows. Duplicates only show up after you normalise:

• trim spaces
• upper-case the SKU
• capitalise product names
• write prices with 2 decimals and no currency text ($4.50, 4.5 → 4.50; "1,25" → 1.25)
• use ISO dates (2026/10/01, 01-10-2026 → 2026-10-01; Oct 6 2026 → 2026-10-06)

If you dedupe first, both copies survive.

Step 2: flag missing values, don't guess

• A-002 has no qty. It stays blank with the flag qty missing.
• A-005 has price N/A. It becomes blank and is flagged as unparseable.

Step 3: balance the count

Output:

sku,product_name,price_usd,qty,updated_iso,review_flag
A-001,Blue Mug,4.50,12,2026-10-01,
A-002,Green Mug,4.75,,2026-10-02,qty missing
A-003,Red Plate,6.00,8,2026-10-03,
A-004,Tea Spoon (x4),2.00,30,2026-10-04,
A-005,Bowl,,5,2026-10-05,"price unparseable -> blank, flagged"
A-006,Napkin Pack,1.25,100,2026-10-06,

9 in → 6 out. Removed: 1 blank row + 2 duplicates = 3. And 6 + 3 = 9, so every missing row has a reason.

If output rows plus removed rows don't equal input rows, stop and find the gap before you deliver anything.

Step 4: keep the original and log every change

Leave the input file untouched and write a short log, one line per change, e.g. "line 4 (A-001): exact duplicate of line 3 after normalisation → removed". Anyone can then check your work.

Disclosure: this article was generated by AI from a synthetic teaching example.

If you'd rather hand off a messy CSV, I clean it with a line-by-line log as a small paid service ($15 up to 50 rows, $39 up to 500): https://lanternflows.gumroad.com/l/siacpf

• Service worker registration failed
• chrome.browserAction is undefined

Below is a small made-up teaching example (a tab counter), not a real project or client case. It is a partial migration, checked by reading the files only; it was not run in a browser.

1. The background page has to become a service worker

MV2 (before):

"background": { "scripts": ["background.js"], "persistent": true },
"browser_action": { "default_title": "Tab count" }

MV3 (after):

"background": { "service_worker": "background.js" },
"action": { "default_title": "Tab count" }

MV3 has no persistent background pages. browser_action was renamed action, and chrome.browserAction became chrome.action in code.

2. Don't keep state in a global variable

Before:

let count = 0; // in-memory state: lost when an MV3 worker stops
function refresh() {
  chrome.tabs.query({}, (tabs) => {
    count = tabs.length;
    chrome.browserAction.setBadgeText({ text: String(count) });
  });
}
chrome.tabs.onCreated.addListener(refresh);
chrome.tabs.onRemoved.addListener(refresh);
refresh();

The service worker is stopped when idle, so count is lost. After:

async function refresh() {
  const tabs = await chrome.tabs.query({});
  await chrome.action.setBadgeText({ text: String(tabs.length) });
}
chrome.tabs.onCreated.addListener(refresh);
chrome.tabs.onRemoved.addListener(refresh);
chrome.runtime.onStartup.addListener(refresh);
chrome.runtime.onInstalled.addListener(refresh);

What changed:

Listeners stay registered at the top level so they are there whenever the worker restarts.

What this does not cover

Content scripts, webRequest → declarativeNetRequest, removing remote code, splitting host_permissions, options pages, and Chrome Web Store review. Each one is a separate job. Check the official Chrome MV3 migration guide before relying on this.

Disclosure: this article was generated by AI from a synthetic teaching example.

If you have one specific extension error you want fixed, I do that as a small paid service ($49 for one defined fix): https://lanternflows.gumroad.com/l/enydiq

Scope of this article: documented against self-hosted n8n 2.44.6. Not tested on n8n Cloud. Notification examples elsewhere in related starters use Slack or SMTP only.

What the Gmail Trigger actually does

The Gmail Trigger polls Gmail on an interval (often about every minute by default, depending on your Poll Times). Each successful poll should only return new messages that match your filters. It is not a push webhook from Google unless you deliberately use a different push-style setup.

So “not working” usually means one of: workflow inactive, OAuth broken, filters too tight, poll never running in production, or you only tested with Execute workflow in the editor.

Checklist: why Gmail Trigger stays quiet

Work top to bottom.

1. Workflow not published / not active

Triggers that poll on a schedule need a published workflow. Draft-only saves do not keep listening in production.

Fix: publish / activate. Confirm the workflow is active. Watch Executions after the next poll window.

2. OAuth / Google Cloud client (self-hosted classic)

Self-hosted n8n needs your own Google Cloud OAuth client with the Gmail API enabled, redirect URI copied from the n8n credential dialog, and a completed Sign in with Google.

Common breaks:

• Redirect URI mismatch
• Gmail API not enabled on the GCP project
• App in Testing with an expired test-user grant (Google often forces reconnect about every 7 days in Testing)
• Wrong Google account authorized (personal vs Workspace)

Fix: open the credential → reconnect. Confirm the same Google user owns the inbox you are watching. Re-check redirect URI character-for-character.

3. You only ran a manual test in the editor

Clicking Execute workflow can exercise downstream nodes with pinned or sample data without proving the trigger poll path. A green canvas after a manual run does not mean the trigger is polling.

Fix: publish, wait at least one full poll interval, send yourself a matching test email, then inspect Executions for a production run that started from the Gmail Trigger.

4. Filters and labels exclude the message

Search filters, label filters, “unread only,” spam/trash exclusions, or a filter aimed at the wrong mailbox will yield successful polls with zero items. That looks identical to “not triggering” from outside.

Fix: temporarily loosen filters. Confirm the test message is in the primary inbox (or the exact label you filter on). Remember: simple mode often exposes a snippet / preview, not the full body—filters that expect full-body text can miss.

5. Poll Times / missed window / rate limits

If Poll Times are very sparse, you may be waiting longer than you think. If Google returns errors (quota, invalid_grant), the execution list shows failures—open them instead of assuming silence means “no mail.”

Fix: read the error text on failed executions. For invalid_grant, reconnect OAuth. For quota, slow the poll or reduce parallel Gmail workflows.

6. Downstream nodes fail (false “trigger broken”)

The trigger may have returned messages, then a label / Slack / LLM node failed. From Slack’s point of view “nothing happened.”

Fix: open the execution graph. If Gmail Trigger has items and a later node is red, fix that node (Slack invite/scopes, missing label IDs, LLM key)—not the trigger credential.

7. Empty / no-preview messages

Some triage workflows intentionally skip messages with empty preview text before any AI call. Those runs can look “idle” even though the trigger fired.

Fix: know whether your workflow has a “has content?” gate. Test with a normal plain-text email that has a non-empty snippet.

Minimal documented pattern (inbox triage shape)

A common production shape:

1. Gmail Trigger (poll) with credentials fixed.
2. Normalize sender / subject / preview.
3. Optional empty-content skip.
4. Classify (rules and/or LLM).
5. Apply Gmail labels; optional Slack urgent alert.
6. Publish; verify with a real test email in production mode.

Documented against self-hosted n8n 2.44.6; not tested on n8n Cloud. Real Gmail OAuth, labels, Slack, and LLM quality still need verification in your Google project and workspace.

Free starter (alerts & digest) while you harden Gmail

If you want something importable that does not depend on Gmail OAuth first—failure alerts (Error Trigger → SMTP) plus RSS → AI digest and a small feedback → Slack starter—the free pack is W5-lite + W6 + W7:

• Free starter (3 documented workflows, $0+ / pay what you want): https://lanternflows.gumroad.com/l/ai-ops-starter-free?utm_source=hashnode&utm_medium=article&utm_campaign=tt_gmail_trigger

The full version is in the free starter pack.

Documented on self-hosted n8n 2.44.6; not tested on n8n Cloud. Import-checked with sample data; real Gmail/Slack/SMTP/LLM behaviour still needs your own verification.

Disclosure: I made the free starter linked here and also sell a related paid n8n pack on Gumroad. No affiliate links in this post.

This post was generated with an AI agent and reviewed by me before publishing.

Scope of this article: documented against self-hosted n8n 2.44.6. Not tested on n8n Cloud. When this article mentions alerts or digests, delivery examples use SMTP (or Slack elsewhere in the free pack)—not Telegram/Discord.

What “RSS Trigger” usually means in practice

In many setups people mean either:

1. RSS Feed Read (or similar read node) on a Schedule / Cron, or
2. An RSS / feed Trigger node that polls on its own interval.

Both fail for similar reasons: bad URL, inactive workflow, empty window, or “success with zero items.” Treat “not working” as no useful items reached the next node, not only a red error banner.

Checklist: why the feed path is silent

Work top to bottom.

1. The workflow is not published / active

Schedule and poll triggers only run in production on a published (activated) workflow. A manual Execute workflow click in the editor does not prove the schedule will fire overnight.

Fix: publish the workflow. Confirm it shows as active. Wait for the next poll window, then check Executions—not only the editor toast.

2. You are testing with a feed URL that does not return items

Broken HTTPS, 403 from the publisher, HTML login pages, Atom vs RSS mismatch, or a URL that used to work and now redirects can all look like “trigger not working.”

Fix: open the feed URL in a browser or curl. You should see XML (or a known feed format), not an empty 200 HTML page. Temporarily put a well-known public feed in Config, publish, and re-test. Put your real feeds back only after the path works.

3. Polling / schedule interval vs your expectations

If the schedule is “every day at 08:00” and you tested at 08:05 in the editor, you did not exercise the schedule. If a trigger polls every N minutes, the first production wait can be a full interval.

Fix: use a Manual Trigger “Run now” path (if your workflow has one) for import checks; keep the schedule for production. Align timezone on the n8n instance with the schedule you wrote.

4. Filters discarded everything (looks like “not working”)

Common silent filters:

• Last N hours only (e.g. last 24h) when the feed’s pubDate is older or missing
• Remove duplicates / already sent on a second run (correct behaviour: nothing new → no email)
• Limit / cap after an empty upstream
• Continue-on-error on Read RSS: one bad feed is skipped; if all feeds fail, you get zero items and no digest

Fix: on a test run, inspect each node’s output item count. Temporarily widen the lookback or clear the duplicate store for a controlled re-test. Do not treat “second run sent nothing” as a broken trigger if the first run already consumed those links.

5. Credentials and downstream SMTP (false “trigger” reports)

The feed may have fired, but Send Email (SMTP) failed on bad host/port/app password. From the inbox’s point of view the digest “never worked.”

Fix: open the failed execution. If RSS nodes produced items and SMTP is red, fix SMTP—not the feed URL. Prefer app passwords where the provider requires them.

6. Instance / network (self-hosted)

Outbound HTTPS from the n8n host must reach the feed origin. Corporate DNS, missing CA bundle, or IPv6-only oddities show up as read errors in Executions.

Fix: from the same host/container that runs n8n, fetch the feed URL. Fix proxy/CA settings if the host cannot reach the public internet the way your laptop can.

Minimal documented pattern (RSS → daily digest email)

A practical shape many people want:

1. Schedule (e.g. daily) + optional Manual Trigger for tests.
2. Config (Set): feed URL list, toEmail / fromEmail, lookback hours, max articles.
3. Split feeds → RSS Feed Read (continue on error per feed if you want bad sources skipped).
4. Time window filter → dedupe → limit → slim fields → aggregate.
5. Optional LLM “write digest” (continue on error if email must still send a fallback).
6. Send Email (SMTP).
7. Publish. Verify with Run now, then let the schedule run once in production.

Documented on self-hosted n8n 2.44.6; not tested on n8n Cloud. Import-checked patterns with sample data still need your own feed and SMTP verification.

Free starter you can import

I packaged an RSS → AI daily digest (plus a failure-alert workflow and a negative-feedback → Slack starter) as a free pack: W5-lite + W6 + W7.

• Free starter (3 documented workflows, $0+ / pay what you want): https://lanternflows.gumroad.com/l/ai-ops-starter-free?utm_source=hashnode&utm_medium=article&utm_campaign=tt_rss_feed

The full version is in the free starter pack.

Documented on self-hosted n8n 2.44.6; not tested on n8n Cloud. Import-checked with sample data; real RSS publishers, SMTP, and LLM behaviour in your environment still need your own verification.

Disclosure: I made the free starter linked here and also sell a related paid n8n pack on Gumroad. No affiliate links in this post.

This post was generated with an AI agent and reviewed by me before publishing.

This is one of the most common “it should work” traps in n8n. Search results for n8n error workflow not triggering are mostly docs and forum threads, so here is a single checklist you can walk through in about ten minutes.

Scope of this article: documented against self-hosted n8n 2.44.6. Not tested on n8n Cloud. Notification examples use Slack or SMTP only.

What an Error Workflow actually is

An Error Workflow is a normal workflow whose first node is an Error Trigger. You point other workflows at it under Settings → Error workflow. When a monitored workflow fails in the way n8n considers “unhandled,” the Error Trigger runs and you can send Slack or email.

It is not a global catch-all for every red node you see while clicking around in the editor.

Checklist: why it is “not triggering”

Work top to bottom. Most “not triggering” reports are one of these.

1. You tested with a manual run in the editor

Error Workflows are meant for automatic / production executions (schedules, webhooks, app triggers on a published workflow). A manual Execute workflow click in the canvas often will not invoke the Error Workflow.

Fix: publish (activate) a throwaway workflow, give it a real trigger (or Schedule), force a failure there, then check Executions on the Error Workflow—not only the editor toast.

2. The Error Workflow is not selected on the failing workflow

Open the workflow that failed → Settings (or Options → Settings) → Error workflow → pick your handler → save / publish again.

In newer n8n versions, both the monitored workflow and the error handler may need to be published. If you only saved a draft, production failures will not see the setting.

3. The failure was “handled,” so n8n does not escalate

If a node uses Continue On Fail, or you wired the node’s error output and handled it yourself, the execution can finish without counting as an unhandled workflow failure. The Error Trigger stays quiet.

Fix: for the path you want alerts on, turn off Continue On Fail and do not swallow the error on a side branch—or accept that handled errors will not page you.

4. The Error Trigger is not the first node (or the handler itself errors)

The handler must start with Error Trigger. Keep the alert path short: Error Trigger → Set/Compose → Slack or Send Email (SMTP). Avoid putting fragile HTTP/LLM steps on the critical path unless they are set to continue on error and are clearly optional.

5. You are looking at the wrong place for proof

Production Error Workflow runs show up under Executions for that workflow. They may not paint a big banner on the workflow that failed. Confirm:

• the failing workflow has a failed production execution;
• the Error Workflow has a matching new execution at about the same time;
• Slack/SMTP credentials on the handler are valid (a bad credential makes it look like “nothing happened”).

6. Instance / URL gotchas (self-hosted)

If your alert includes an execution link, the instance public URL must be configured correctly, or the link is useless even when the trigger did fire. That is a separate issue from “not triggering,” but it is often reported together.

Minimal documented pattern (Slack or SMTP)

1. New workflow → Error Trigger.
2. Edit Fields (Set) for subject/channel/recipient prefixes.
3. Slack Send message or Send Email (SMTP) with workflow name, failed node, error message, and execution URL from the Error Trigger payload.
4. Publish the handler.
5. On every workflow you care about: Settings → Error workflow → select it → publish.

To force a failure on purpose: add a Stop And Error node on a published schedule/webhook workflow, run it once in production mode, then verify the handler execution.

Optional AI “explain this error” steps are fine only if they cannot block the alert (continue on error, off by default).

Free starter you can import

I packaged this pattern as a small failure-alert workflow (plus two other starters: negative-feedback → Slack, and RSS → AI daily digest by email). Free pack = W5-lite + W6 + W7.

• Free starter (3 documented workflows, $0+ / pay what you want): https://lanternflows.gumroad.com/l/ai-ops-starter-free?utm_source=hashnode&utm_medium=article&utm_campaign=tt_error_workflow

The full version is in the free starter pack.

Documented on self-hosted n8n 2.44.6; not tested on n8n Cloud. Import-checked with sample data; real Gmail/Slack/SMTP/LLM behaviour in your environment still needs your own verification.

Disclosure: I made the free starter linked here and also sell a related paid n8n pack on Gumroad. No affiliate links in this post.

This post was generated with an AI agent and reviewed by me before publishing.