Skip to content

feat: support lock reason in user search - #813

Merged
dorsha merged 4 commits into
mainfrom
feat/18708-lock-reason-search
Oct 7, 2026
Merged

dorsha merged 4 commits into
mainfrom
feat/18708-lock-reason-search

Conversation

@PolinaPrem

Copy link
Copy Markdown
Contributor

Related Issues

Related: descope/etc#18708

Description

Adds lockReasons and tempLockReasons to SearchRequest. The deprecated positional searchAll is unchanged. The response type lives in core-js-sdk, which needs lockReason?: string; tempLockExpiration?: number; on UserResponse in a separate descope-js change.

tempLockExpiration is unix seconds (0 when none). A user is temporarily locked while tempLockExpiration > now. TOTP has no temporary lock, so tempLockReasons accepts only password, recovery_codes and security_questions.

Must

  • Tests
  • Documentation (if applicable)

🤖 Generated with Claude Code

Add lockReasons and tempLockReasons to SearchRequest (descope/etc#18708)
@PolinaPrem
PolinaPrem force-pushed the feat/18708-lock-reason-search branch from d6bd15f to 322f08e Compare October 5, 2026 13:35
@PolinaPrem PolinaPrem changed the title feat: add lock reason filters to user search feat: support lock reason in user search Oct 5, 2026
@PolinaPrem
PolinaPrem marked this pull request as ready for review October 5, 2026 13:42

@dorsha dorsha left a comment •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

The request side looks right: both filters pass through search and searchTestUsers and are dropped when unset.

Gap: search returns UserResponse from @descope/core-js-sdk, which has no lockReason / tempLockExpiration (on main or on descope-js#1505). So user.lockReason is a TypeScript error here, while Go, Java and Python expose it. Suggest adding both fields to core-js-sdk's UserResponse (I suggested it on descope-js#1505) and bumping core here before release.

core-js-sdk's UserResponse has no lockReason / tempLockExpiration yet, so UserSearchResponse now uses a node-sdk UserSearchResult that adds both (descope/etc#18708)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shuni-bot

shuni-bot Bot commented Oct 6, 2026 •

Copy link
Copy Markdown
Contributor

🐕 Shuni Review

No new issues found.

🤖 Model: claude-opus-5.5 · Effort: high


Review scope: Partial incremental re-review

Reviewed new changes (3)
  • lib/management/user.test.ts
  • package.json
  • package-lock.json
Previously reviewed and unchanged: 1 file.

🐕 Review complete — View session on Shuni Portal 🐾

🤖 Model: claude-opus-5.5 · Effort: high

@shuni-bot shuni-bot Bot left a comment

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.

🐕 Shuni review: no new findings. Every changed file in this pull request was reviewed.

The full review summary is in Shuni's sticky review comment on this pull request.

…stead

This reverts commit 4e3ce94. lockReason and tempLockExpiration are added to core-js-sdk's UserResponse in descope/descope-js#1507; core is bumped here once that's released.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@PolinaPrem

Copy link
Copy Markdown
Contributor Author

Added them to cores UserResponse: descope/descope-js#1507. I'll bump core here once its released.

@shuni-bot shuni-bot Bot left a comment

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.

🐕 Shuni review: no new findings. Every changed file in this pull request was reviewed.

The full review summary is in Shuni's sticky review comment on this pull request.

dorsha pushed a commit to descope/descope-js that referenced this pull request Oct 6, 2026
descope/etc#18708

## Related PRs

- Follow-up to descope/node-sdk#813, which types these fields on search
results only, via a node-sdk `UserSearchResult`
- Related: #1505 (user management widget lock reason)

## Description

The user APIs return two brute-force lock fields that `UserResponse`
doesn't type, so SDK consumers can only read them with a cast:

- `lockReason?: string` - the auth method that triggered brute-force
protection (`password`, `totp`, `recovery_codes`, `security_questions`),
empty when none
- `tempLockExpiration?: number` - when a temporary lock ends, in unix
seconds (0 when none). The user is temporarily locked while this is
greater than now

Types only. Both fields are optional, so nothing changes for existing
callers or for backends that don't return them. Once this is released,
node-sdk can drop `UserSearchResult` and `load` and the other user
methods get the fields too.

## Must

- [x] Tests (existing suite passes; the change is type-only)
- [ ] Documentation (if applicable)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
core-js-sdk 2.75.0 adds lockReason and tempLockExpiration to UserResponse (descope/descope-js#1507), so search results expose them (descope/etc#18708)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@shuni-bot shuni-bot Bot left a comment

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.

🐕 Shuni review: no new findings. Every changed file in this pull request was reviewed.

The full review summary is in Shuni's sticky review comment on this pull request.

@dorsha
dorsha merged commit 9f4b6d4 into main Oct 7, 2026
29 checks passed
@dorsha
dorsha deleted the feat/18708-lock-reason-search branch October 7, 2026 15:19
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.

2 participants