Bug Description

The expression-based role mapping feature for SSO (introduced via PRs #27688/#27689/#27745, Linear IAM-397) has two interacting bugs that cause silent data corruption and missing rules in the UI.

Bug 1 — UI display cap (frontend): GET /rest/role-mapping-rule returns only the first 10 items by default. The UI does not paginate or pass ?take=N, so any rule beyond the 10th is invisible in Settings → SSO. With one instance rule plus N project rules, the Project role rules section displays only the first 9 project rules — the 10th and beyond are missing entirely from the UI despite existing server-side.

Bug 2 — Save flow creates duplicates instead of updating: Saving changes via the UI appears to create new rows for existing rules rather than updating them, leaving orphan duplicates. Repeated edits multiply the duplicates. We observed 33 rows for 11 logical rules before manually cleaning up via the REST API.

Combined impact: Rules silently accumulate. The provisioning service evaluates all rows including duplicates; first match wins by order, so any edit that introduces a divergent duplicate at a lower order would silently override the intended rule. The UI is not a faithful view of backend state, making the feature hard to audit.

Backend supports pagination, frontend does not use it:

• GET /rest/role-mapping-rule → count=11, items=10
• GET /rest/role-mapping-rule?take=100 → count=11, items=11 ✅
• GET /rest/role-mapping-rule?limit=100 → count=11, items=10 (param ignored)
• GET /rest/role-mapping-rule?skip=10 → returns rule 11 ✅

Duplication pattern after multiple saves (identical expression/role/projectIds, only id and order differ; all duplicates share the same updatedAt):

The duplicate count per expression correlates directly with how many times that rule was edited — strong signal that each save creates rather than updates. The frontend issues PATCH calls per rule on save (returning 200), but the PATCH does not appear to update the underlying rows; new rows with new ids appear in subsequent GETs.

Suggested fixes:

• Frontend list: paginate, or pass a sufficient take parameter on the existing single call. Show the total rule count in the UI so admins can spot UI/backend mismatches.
• Save flow: ensure the UI's save path issues PATCH against existing ids rather than creating new rows. If PATCH is already being sent, the backend handler for the role-mapping-rule PATCH endpoint needs investigation.
• Migration: consider a one-shot dedup migration for affected instances, or expose an admin "rebuild rules" action.

References: Feature PRs #27440, #27569, #27688, #27689, #27745. Linear IAM-395, IAM-397, IAM-483.

To Reproduce

1. Configure SAML or OIDC with expression-based role mapping ("Map rules inside n8n")
2. Add 10 or more rules via the UI (mix of instance and project rules)
3. Observe that only the first 10 rules are visible in the UI — the 11th and beyond do not render, even though they exist server-side (verify with curl -H "Cookie: n8n-auth=..." /rest/role-mapping-rule?take=100)
4. Edit any visible rule and click Save
5. Re-fetch via the REST API — observe a new row with a new id and a higher order value, while the original row still exists unchanged
6. Repeat step 4 several times for the same rule; observe duplicate row count increases with each save

<img width="1403" height="788" alt="Image" src="https://github.com/user-attachments/assets/952c534b-96c8-41f2-9b14-cd09c796dcd8" /> <img width="1123" height="271" alt="Image" src="https://github.com/user-attachments/assets/255260dc-4ea5-4411-8a44-77d6ccd4aed6" />

Expected behavior

1. The UI should display all role mapping rules regardless of how many exist (paginating if necessary), and provide a visible total count so admins can verify UI matches backend state.
2. Saving an existing rule should issue PATCH against the existing row by id and update in place — not create a new row. The set of rule IDs in the database should remain stable across saves that don't add or remove rules.

Debug Info

Debug info

core

• n8nVersion: 2.21.4
• platform: docker (cloud)
• nodeJsVersion: 24.15.0
• nodeEnv: production
• database: sqlite
• executionMode: regular
• concurrency: 200
• license: enterprise (production)
• consumerId: 729bdf4b-a72f-48ea-bd06-4b5dc3757190

storage

• success: all
• error: all
• progress: false
• manual: true
• binaryMode: filesystem

pruning

• enabled: true
• maxAge: 720 hours
• maxCount: 25000 executions

client

• userAgent: mozilla/5.0 (macintosh; intel mac os x 10_15_7) applewebkit/537.36 (khtml, like gecko) chrome/148.0.0.0 safari/537.36
• isTouchDevice: false

cluster

• instanceCount: 1
• versions: 2.21.4
• instances:
  • instanceKey: 1dde3729-43ca-4e9a-96e2-84de38b93752, hostId: main-snowplow-dev-n8n-79cdd78467-kq2l7, instanceType: main, instanceRole: leader, version: 2.21.4
• checks:
  • check: hostid-clash, status: succeeded, warnings: -
  • check: lifecycle, status: succeeded, warnings: -
  • check: split-brain, status: succeeded, warnings: -
  • check: version-mismatch, status: succeeded, warnings: -

Generated at: 2026-05-21T09:17:02.529Z

Operating System

N/A - Cloud Hosted

n8n Version

2.21.4

Node.js Version

N/A

Database

SQLite (default)

Execution mode

main (default)

Hosting

n8n cloud