Skip to content

fix(auth): user limit resets to 100 on page refresh when policy is unset#3135

Open
okxint wants to merge 1 commit into
appwrite:mainfrom
okxint:fix/auth-limit-default-hardcoded
Open

fix(auth): user limit resets to 100 on page refresh when policy is unset#3135
okxint wants to merge 1 commit into
appwrite:mainfrom
okxint:fix/auth-limit-default-hardcoded

Conversation

@okxint

@okxint okxint commented Jul 22, 2026

Copy link
Copy Markdown

After the listPolicies migration, the user limit field in Auth > Security shows 100 on hard refresh regardless of the configured value.

Two bugs introduced by that migration:

  1. +page.ts had no fallback default for userLimitPolicy when the policy is absent from the API response (i.e., never explicitly configured). passwordStrengthPolicy had a ?? getDefault...() guard; userLimitPolicy did not. This caused the component to receive undefined, making policy.total !== 0 evaluate to false and triggering the hardcoded 100 fallback.

  2. updateUsersLimit.svelte initialized value/newLimit from the policy prop using $state(). In Svelte 5 runes mode, $state() runs once at mount and does not react to prop changes. After invalidate(Dependencies.PROJECT) re-fetches data and updates the policy prop, the form values stayed stale.

Fixes:

  • Added getDefaultUserLimitPolicy() returning { $id: ProjectPolicyId.Userlimit, total: 0 } and applied it as a fallback in +page.ts (matching the existing pattern for other policies).
  • Added a $effect in updateUsersLimit.svelte to re-derive value/newLimit from the policy prop on updates.

…oded 100

listPolicies omits the user limit policy entirely when no limit has been
configured, making userLimitPolicy undefined. The component then fell back
to the hardcoded 100 default. Added getDefaultUserLimitPolicy() to match the
pattern already used for passwordStrengthPolicy, and added a $effect in the
component so value/newLimit stay in sync with the policy prop after invalidation.
@greptile-apps

greptile-apps Bot commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR fixes how the Auth security page handles the user-limit policy.

  • Adds a default user-limit policy when the API does not return one.
  • Uses that default in the security page loader.
  • Adds a Svelte effect to resync the user-limit form from refreshed policy props.

Confidence Score: 4/5

The user-limit form can discard unsaved edits after project policy refreshes.

  • The loader fallback follows the existing policy-default pattern.
  • The new form sync runs on refreshed props and overwrites editable local state.
  • Unrelated policy saves on the same page can trigger that refresh before the user saves the limit.

src/routes/(console)/project-[region]-[project]/auth/security/updateUsersLimit.svelte

Important Files Changed

Filename Overview
src/routes/(console)/project-[region]-[project]/auth/security/+page.ts Adds a fallback user-limit policy so the page receives a defined policy object when the API omits it.
src/routes/(console)/project-[region]-[project]/auth/security/updateUsersLimit.svelte Adds prop-to-form synchronization, but the effect can overwrite unsaved local edits after project data refreshes.

Fix All in Claude Code Fix All in Codex

Prompt To Fix All With AI
Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
src/routes/(console)/project-[region]-[project]/auth/security/updateUsersLimit.svelte:26-29
**Policy Refresh Discards Edits**

When any security policy form on this page saves, it invalidates the project data and refreshes `data.userLimitPolicy`. This effect then copies the refreshed policy back into `value` and `newLimit`, so a user who is editing the user limit can lose their unsaved radio or number input after an unrelated policy update.

Reviews (1): Last reviewed commit: "fix(auth): initialize user limit from pr..." | Re-trigger Greptile

Comment on lines +26 to +29
$effect(() => {
value = policy.total !== 0 ? 'limited' : 'unlimited';
newLimit = policy.total !== 0 ? policy.total : 100;
});

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Policy Refresh Discards Edits

When any security policy form on this page saves, it invalidates the project data and refreshes data.userLimitPolicy. This effect then copies the refreshed policy back into value and newLimit, so a user who is editing the user limit can lose their unsaved radio or number input after an unrelated policy update.

Context Used: AGENTS.md (source)

Knowledge Base Used: Messaging, Storage, and Auth in the project console

Prompt To Fix With AI
This is a comment left during a code review.
Path: src/routes/(console)/project-[region]-[project]/auth/security/updateUsersLimit.svelte
Line: 26-29

Comment:
**Policy Refresh Discards Edits**

When any security policy form on this page saves, it invalidates the project data and refreshes `data.userLimitPolicy`. This effect then copies the refreshed policy back into `value` and `newLimit`, so a user who is editing the user limit can lose their unsaved radio or number input after an unrelated policy update.

**Context Used:** AGENTS.md ([source](https://app.greptile.com/appwrite/github/appwrite/console/-/custom-context?memory=f4227d43-a98a-4882-876a-cad1bc006878))

**Knowledge Base Used:** [Messaging, Storage, and Auth in the project console](https://app.greptile.com/appwrite/-/custom-context/knowledge-base/appwrite/console/-/docs/messaging-storage-authusers.md)

How can I resolve this? If you propose a fix, please make it concise.

Fix in Claude Code Fix in Codex

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant