fix(editor): Clear tag loading state after failed requests

[Suzu1Dev]

Summary

A failed tag-list request leaves the tag store in a loading state. When the tag manager already has tags, the error message can appear while search and Add new remain disabled and the table keeps its loading overlay.

Reset loading in finally so it clears after success or failure. Keep the original error for the caller. Keep cached tags when a refresh fails. The shared implementation covers workflow tags and execution annotation tags.

How to test

From packages/frontend/editor-ui, run:

pnpm test src/features/shared/tags/tags.store.test.ts src/features/shared/tags/components/WorkflowTagsDropdown.test.ts src/features/shared/tags/components/TagsDropdown.innerSelect.test.ts src/features/shared/tags/components/TagsManager/TagsView/TagsTableHeader.test.ts
pnpm lint
pnpm typecheck

The six new cases cover both store types:

• Loading stays active while a request is pending and clears after success.
• A rejected request clears loading and propagates the same error. A later request succeeds.
• A failed forced refresh clears loading and keeps cached tags available.

Apply only this PR's test-file changes to base revision 909a6bc60aaaf926653a5f802f6a503f73c2a439 to reproduce the failure. Run the tag-store suite. Four cases fail and ten pass. Each failure shows that isLoading remains true after the API rejects. With the production fix, all 14 store cases pass. The 12 related component cases also pass.

The tests mock the tag API. No live service is required. Browser interaction was not used for validation. The UI effects in the summary follow from the component bindings.

Local validation also passed editor lint and typecheck, repository typecheck, and repository lint. The repository lint check combined package checks, 129 successful tasks, and two valid cached results. The initial main run reached Node's default heap limit in the CLI package. Recovery used an 8 GB heap setting.

Related Linear tickets, Github issues, and Community forum posts

Fixes #37900.

Internal tracking: https://linear.app/n8n/issue/GHC-9417.

Review / Merge checklist

• I have seen this code, I have run this code, and I take responsibility for this code.
• PR title and summary are descriptive. (conventions)
• Docs updated or follow-up ticket created.
• Tests included.
• PR Labeled with Backport to Beta, Backport to Stable, or Backport to v1 (if the PR is an urgent fix that needs to be backported)

🤖 PR Summary generated by AI

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

<sub>Shadow auto-approve: would not auto-approve. Auto-approval skipped because this PR is from an external contributor.

Re-trigger cubic</sub>

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
🔒 Security Review	✅ Completed 2026-09-04T22:47:17.287009Z	1350a31	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[n8n-assistant]

Hey @Suzu1Dev,

Thank you for your contribution. We appreciate the time and effort you’ve taken to submit this pull request.

Before we can proceed, please ensure the following: • Your PR references the GitHub issue it fixes (or, for feature requests, a link to the corresponding community forum post). • Tests are included for any new functionality, logic changes or bug fixes. • The PR aligns with our contribution guidelines.

Why the linked issue matters: Our teams pick up work from the issue, not from individual pull requests — the issue is what reaches them, with your PR linked to it. So please make sure the issue contains everything needed to judge the change: a clear problem description, reproduction steps, and the expected behaviour. If the issue is thin, add the missing context there rather than only in the PR description.

Regarding new nodes: We no longer accept new nodes directly into the core codebase. Instead, we encourage contributors to follow our Community Node Submission Guide to publish nodes independently.

If your node integrates with an AI service that you own or represent, please email nodes@n8n.io and we will be happy to discuss the best approach.

About review timelines: While we plan to review it as soon as possible, we are currently unable to provide an exact timeframe. Our goal is to begin reviews within a month, but this may change depending on team priorities. We will reach out when the review begins.

Please also note that other contributors may have opened pull requests for the same issue. We keep them all open so the reviewing team can choose the approach that fits best. Once the issue is resolved, the remaining pull requests are closed — this is not a judgement on the quality of your work, and we're grateful for it either way.

Thank you again for contributing to n8n.