Skip to content

Tag loading state remains active after a failed request #37900

Description

@Suzu1Dev

Bug Description

A failed tag-list request leaves the tag store in a loading state. The request rejects, but fetchAll() does not reset loading.

The tag manager catches the error and shows a message. If the view already has tags, its search field and Add new button remain disabled. The table also keeps its loading overlay. The tag dropdown uses the same store state.

Workflow tags and execution annotation tags use the same store implementation. Both are affected.

To Reproduce

Use a local unit test with a mocked tag API. No running n8n instance is required.

  1. Create the workflow tag store or the annotation tag store with list permission.
  2. Seed the store with one tag.
  3. Make the next getTags() call return a pending promise.
  4. Call fetchAll({ force: true }).
  5. Check that isLoading is true.
  6. Reject the API promise with an error.
  7. Await the rejection from fetchAll().
  8. Check isLoading. It remains true in the original code.

The expected value after step 7 is false. The original error must still reach the caller. The cached tag must remain available. A later request must be able to load tags successfully.

The regression tests are available in the fork. Apply only the test-file changes to the base revision below to reproduce the failure. The test command runs from packages/frontend/editor-ui:

pnpm test src/features/shared/tags/tags.store.test.ts

Expected behavior

The store must reset loading after the request succeeds or fails. A failed request must keep the existing tag data and reject with the original error. The tag manager must stop showing loading while it reports the error.

Debug Info

This report uses the source checkout at revision 909a6bc60aaaf926653a5f802f6a503f73c2a439. It is not a report from a running deployment.

Affected source: packages/frontend/editor-ui/src/features/shared/tags/tags.store.ts.

The UI effects above follow from the component bindings. Browser interaction was not used to reproduce this report.

The updated tag-store suite has 14 cases. With the original production file, 4 cases fail and 10 pass. Each failing case expects loading to clear after a rejected request. With the fix, all 14 cases pass. The 12 related tag component tests also pass.

The regression cases cover both store types. They check pending requests, error propagation, successful retries, and cached data after failed refreshes.

Operating System

macOS 27.0.

n8n Version

2.37.0 (source checkout).

Node.js Version

24.1.0. The test environment uses pnpm 11.25.0.

Database

Not applicable. The unit tests mock the API and do not connect to a database.

Execution mode

Not applicable. The reproduction runs the frontend unit suite.

Hosting

Local source checkout. No cloud or self-hosted deployment was used.

Proposed fix

Reset loading in a finally block in fetchAll(). Keep the existing API result, error propagation, and cached tag data behavior.

The change is limited to the frontend tag store and its tests. It does not change permissions, credentials, or the workflow execution engine.

Related history: #6019 reported a similar visible symptom from a server-side tag query error. That issue is closed. This report covers frontend loading cleanup when a tag-list request rejects.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    status:in-linearIssue or PR is now in Linearstatus:team-assignedA team has been assigned the issue or PRteam:adoreIssue is with the Adore team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions