Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@kongadurgesh
Copy link
Contributor

@kongadurgesh kongadurgesh commented Dec 2, 2025

Summary by CodeRabbit

Release Notes

  • Documentation

    • Added comprehensive OpenID4VP Integration Guide covering end-to-end authorization flows, security considerations, error handling, and integration guidance for verifiers.
  • New Features

    • Introduced new authorization page streamlining verifier-presented credential flows with enhanced trust verification and credential filtering.
  • Improvements

    • Enhanced application stability through refined error handling and component architecture updates.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link

coderabbitai bot commented Dec 2, 2025

Walkthrough

This PR introduces comprehensive OpenID4VP integration documentation and refactors the codebase to support verifier-presented (VP) authorization flows. Changes include routing updates to use the new VPAuthorizationPage component, component/hook naming standardizations (e.g., InfoTooltipTriggerInfoTooltip, LoadingModalLoaderModal), error handling simplification with type renames, and internal callback refactoring across multiple handlers.

Changes

Cohort / File(s) Summary
Documentation
docs/OpenID4VPIntegrationGuide.md
New comprehensive OpenID4VP integration guide for Verifiers using INJI Web Wallet, including authorization flow, presentation definitions, sequence diagrams, security considerations, and step-by-step integration guidance.
Routing Update
inji-web/src/Router.tsx
Updated authorization route to render VPAuthorizationPage instead of UserAuthorizationPage.
New VP Authorization Page
inji-web/src/pages/VPAuthorizationPage.tsx
New React component orchestrating the verifier-presented authorization flow, including verifier validation, trust management, credential selection, and sharing logic with modal interactions.
InfoTooltip Component Refactor
inji-web/src/components/Common/ToolTip/InfoTooltip.tsx, inji-web/src/components/Issuers/TrustVerifierModal.tsx
Renamed exported component from InfoTooltipTrigger to InfoTooltip and updated prop type accordingly; updated consumer imports and usage.
InfoTooltip Test Updates
inji-web/src/__tests__/components/Common/ToolTip/InfoTooltip.test.tsx, inji-web/src/__tests__/components/Issuer/TrustVerifierModal.test.tsx
Updated test imports and mocks to reference InfoTooltip instead of InfoTooltipTrigger.
LoaderModal Migration
inji-web/src/modals/LoaderModal.tsx, inji-web/src/handlers/CredentialShareHandler.tsx, inji-web/src/modals/CredentialRequestModal.tsx
Updated import paths and references from LoadingModal to LoaderModal; removed trailing newline in LoaderModal component file.
LoaderModal Test Updates
inji-web/src/__tests__/handlers/CredentialShareHandler.test.tsx, inji-web/src/__tests__/modals/CredentialRequestModal.test.tsx, inji-web/src/__tests__/modals/LoaderModal.test.tsx, inji-web/src/__tests__/pages/VPAuthorizationPage.test.tsx
Updated test mocks and imports to reference LoaderModal instead of LoadingModal.
Error Handling Refactor
inji-web/src/utils/errorHandling.ts, inji-web/src/hooks/useApiErrorHandler.ts
Simplified StandardError type (removed message, context, timestamp); renamed ErrorHandlingOptions to ErrorOptions; removed createUserError export; narrowed HTTP status mappings; updated error normalization and logging logic.
useApiErrorHandler Hook Updates
inji-web/src/hooks/useApiErrorHandler.ts
Renamed config property retryableErrorCodes to errorCodesToRetry; renamed interface UseApiErrorHandlerReturn to UseApiErrorHandlerProps; updated dependency arrays.
Error Handling Test Updates
inji-web/src/__tests__/hooks/useApiErrorHandler.test.ts, inji-web/src/__tests__/utils/errorHandling.test.ts
Updated tests to use errorCodesToRetry instead of retryableErrorCodes; updated StandardError assertions to check originalError instead of message/timestamp.
Callback Refactoring
inji-web/src/handlers/CredentialShareHandler.tsx, inji-web/src/modals/CredentialRequestModal.tsx, inji-web/src/modals/NoMatchingCredentialsModal.tsx
Internal callback renames for consistency: submitPresentationCoresubmitPresentationCallback, fetchCredentialsCorefetchCredentialsCallback, rejectVerifierCorerejectVerifierCallback; updated all call sites and dependency arrays.
Credential Component Updates
inji-web/src/components/Credentials/CredentialItem.tsx
Refactored to use inline memo wrapper in export instead of separate component declaration.
PasscodePageTemplate Props Update
inji-web/src/components/PageTemplate/PasscodePage/PasscodePageTemplate.tsx, inji-web/src/pages/User/Passcode/PasscodePage.tsx
Removed public testIdSuffix prop from PasscodePageTemplateProps; updated consumers to compute combined testId string.
Type Removals
inji-web/src/types/components.d.ts
Removed exported interfaces CreatePresentationResponse and Presentation.
Miscellaneous
inji-web/src/hooks/useInterceptor.ts
Minor comment correction in 401 unauthorized handling block.

Sequence Diagram

sequenceDiagram
  participant User
  participant VPAuthPage as VPAuthorizationPage<br/>(State Management)
  participant API as Backend API
  participant TrustModal as TrustVerifierModal
  participant CredModal as CredentialRequestModal
  participant ShareHandler as CredentialShareHandler

  User->>VPAuthPage: Mount with verifier request params
  VPAuthPage->>API: validateVerifierRequestCallback<br/>(validate verifier request)
  API-->>VPAuthPage: verificationData & presentationId
  
  alt Verifier Not Trusted
    VPAuthPage->>TrustModal: Show TrustVerifierModal
    User->>TrustModal: Accept verifier
    TrustModal->>API: addTrustedVerifierCallback<br/>(add to trusted list)
    API-->>TrustModal: Success
    TrustModal->>VPAuthPage: onTrustComplete()
  end
  
  VPAuthPage->>CredModal: Show CredentialRequestModal
  User->>CredModal: Select credentials & confirm
  CredModal->>VPAuthPage: handleCredentialRequestConsent
  
  VPAuthPage->>ShareHandler: Present selectedCredentials
  ShareHandler->>API: submitPresentation<br/>(create VP and POST to response_uri)
  API-->>ShareHandler: Success/Error
  ShareHandler->>VPAuthPage: Callback with result
  
  alt Success
    VPAuthPage->>User: Complete flow
  else Error
    VPAuthPage->>VPAuthPage: Show ErrorCard with retry
  end
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

  • Error handling refactor: Significant API surface changes (removed/renamed exports, simplified StandardError type, changed behavior of standardizeError and logError). Requires tracing impact across all error-handling call sites.
  • New VPAuthorizationPage component: New 200+ line component with complex state management, multiple modal interactions, and API integrations. Verify modal sequencing, error handling, and navigation flows are correct.
  • Type removals: CreatePresentationResponse and Presentation interface removals must be verified to ensure no orphaned references remain.
  • Hook signature changes: useApiErrorHandler interface rename and property renames require careful verification that all consumers are updated consistently.
  • Callback renames: While repetitive, ensure all internal callback references and dependency arrays are updated correctly across three separate files.

Possibly related PRs

Suggested reviewers

  • swatigoel
  • jackjain

🐰 A verifier's dream come true,
With VP flows and trusted credentials too,
InfoTooltips gleam, LoaderModals glow,
Error messages simplified, let the auth dance flow!
Type refactors in place, callbacks well-named,
INJI's new journey—authorization reclaimed!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title refers to syncing a release to develop branch, which aligns with the comprehensive changeset including documentation, component refactoring, and API updates across multiple files.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Rudhhi-Shah-14 and others added 5 commits December 2, 2025 12:46
…i#452)

* [INJIWEB-1747] Removed the Authorization request url param from UserAuthorizationPage

Signed-off-by: Rudhhi Shah <[email protected]>

* [INJIWEB-1747] Modified the OpenIDVP authorize prefix to be appended in the validateVerifierRequest

Signed-off-by: Rudhhi Shah <[email protected]>

---------

Signed-off-by: Rudhhi Shah <[email protected]>
Signed-off-by: kongadurgesh <[email protected]>
* [INJIWEB-1747] modified the Authorization page to fix the ?? issue in url

Signed-off-by: Rudhhi Shah <[email protected]>

* [INJIWEB-1747] acknowledged coderabbit comment to handle edge case on cleanParams

Signed-off-by: Rudhhi Shah <[email protected]>

* [INJIWEB-1747] Added new test cases in Auth and UserAuth Page

Signed-off-by: Rudhhi Shah <[email protected]>

---------

Signed-off-by: Rudhhi Shah <[email protected]>
Signed-off-by: kongadurgesh <[email protected]>
…g, Update Props (inji#461)

* [INJIWEB-1783] - Fix PR review comments

Signed-off-by: kongadurgesh <[email protected]>

* [INJIWEB-1783] - Fix Test case after refractor

Signed-off-by: kongadurgesh <[email protected]>

* [INJIWEB-1779] - Update VerifierPresentationPage to VPAuthorizationPage

Signed-off-by: kongadurgesh <[email protected]>

* [INJIWEB-1783] - Update VerifierPresentationPage to VPAuthorizationPage

Signed-off-by: kongadurgesh <[email protected]>

* [INJIWEB-1783] - Fix InfoTooltipProps

Signed-off-by: kongadurgesh <[email protected]>

* [INJIWEB-1783] - Rename test file to VPAuthorizationPage

Signed-off-by: kongadurgesh <[email protected]>

* [INJIWEB-1783] - Update file name from VPAuthorization to VPAuthorizationPage

Signed-off-by: kongadurgesh <[email protected]>

* [INJIWEB-1783] - Update  from VPAuthorization to VPAuthorizationPage

Signed-off-by: kongadurgesh <[email protected]>

---------

Signed-off-by: kongadurgesh <[email protected]>
* [INJIWEB-1770] Create integration guide for OVP flow

Signed-off-by: jackjain <[email protected]>

* [INJIWEB-1770] Fix code review comments

Signed-off-by: jackjain <[email protected]>

* [INJIWEB-1770] Add separate sequence diagram for user rejects verifier flow, fix typos and add more details to descriptions

Signed-off-by: jackjain <[email protected]>

* [INJIWEB-1770] Fix grammar in URL param description

Signed-off-by: jackjain <[email protected]>

---------

Signed-off-by: jackjain <[email protected]>
Signed-off-by: kongadurgesh <[email protected]>
@kongadurgesh kongadurgesh force-pushed the injiweb-1795-sync-release-to-develop branch from f5c866f to 86ea721 Compare December 2, 2025 07:16
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)
inji-web/src/utils/errorHandling.ts (1)

17-35: Inconsistent comment: ERROR_TYPES is exported.

The comment on line 17 states these are "not exported," but ERROR_TYPES is actually exported on line 18.

-// Internal error types and mappings (not exported as they're only used internally)
+// Standard error types for categorizing errors across the application
 export const ERROR_TYPES = {
inji-web/src/components/Common/ToolTip/InfoTooltip.tsx (1)

20-41: Escape key should always close, not toggle the tooltip

Using the same toggle logic for Escape, Enter, and space means pressing Escape when the tooltip is hidden will open it, which is counter to typical a11y expectations (Escape is expected to close only).

Consider handling Escape separately to always hide the tooltip:

-                onKeyDown={(e) => { if (e.key === 'Escape' || e.key === 'Enter' || e.key === ' ') { e.preventDefault(); e.stopPropagation(); handleToggle(); } }}
+                onKeyDown={(e) => {
+                    if (e.key === 'Escape') {
+                        e.preventDefault();
+                        e.stopPropagation();
+                        setShowTooltip(false);
+                        return;
+                    }
+                    if (e.key === 'Enter' || e.key === ' ') {
+                        e.preventDefault();
+                        e.stopPropagation();
+                        handleToggle();
+                    }
+                }}
🧹 Nitpick comments (8)
docs/OpenID4VPIntegrationGuide.md (2)

13-16: Refine sentence variety in the high-level flow section.

Lines 13–16 have three consecutive sentences starting with "User," reducing stylistic variety. Consider rephrasing to improve readability:

- Verifier constructs an OpenID4VP authorization request.
- User is redirected to the INJI Web Wallet (`/authorize`).
- User logs in.
- User reviews verifier details and gives consent.
- User selects an eligible credential matching the `presentation_definition`.

Try something like:

- Verifier constructs an OpenID4VP authorization request.
- User is redirected to the INJI Web Wallet (`/authorize`) and logs in.
- After authentication, the user reviews verifier details and grants consent.
- Credential matching the `presentation_definition` is then selected by the user.

1-429: Comprehensive and well-structured documentation.

The guide covers all essential aspects of OpenID4VP integration: authorization flow, parameter requirements, presentation definitions, client metadata, VP delivery, security considerations, and detailed technical specifications with sequence diagrams. The examples, parameter tables, and error handling section provide practical guidance for implementers.

A few minor notes:

  • Confirm that the documented endpoints and parameter names match the actual implementation.
  • Consider clarifying the boundary between InjiWeb frontend responsibilities and Mimoto backend responsibilities earlier in the document.
  • The references section at the end is valuable; ensure links remain current.
inji-web/src/hooks/useApiErrorHandler.ts (1)

15-33: Consider renaming UseApiErrorHandlerProps to UseApiErrorHandlerResult or similar.

The suffix Props typically denotes input properties to a component/hook, while this interface describes the return value. A name like UseApiErrorHandlerResult or UseApiErrorHandlerReturn would be more idiomatic.

-export interface UseApiErrorHandlerProps {
+export interface UseApiErrorHandlerResult {

And update the return type accordingly:

 export const useApiErrorHandler = (
     retryConfig: RetryConfig = {}
-): UseApiErrorHandlerProps => {
+): UseApiErrorHandlerResult => {

Also applies to: 47-47

inji-web/src/pages/VPAuthorizationPage.tsx (4)

24-24: Consider adding a type for verifierData instead of any.

Using any loses type safety. Consider defining an interface for the verifier data structure.

+interface VerifierData {
+    id: string;
+    name: string;
+    logo?: string;
+    trusted: boolean;
+    redirectUri?: string;
+}
+
 export const VPAuthorizationPage: React.FC = () => {
     // ...
-    const [verifierData, setVerifierData] = useState<any>(null);
+    const [verifierData, setVerifierData] = useState<VerifierData | null>(null);

71-79: Simplify the parameter validation logic.

The try-catch here is misleading since the condition check won't throw an exception. The error is manually thrown, making the catch block unreachable in practice.

-        try {
-            if (!cleanParams || cleanParams === '?') {
-                throw new Error("No query parameters found in URL");
-            }
-        } catch (parseError) {
-            setIsLoading(false);
-            handleApiError(new Error("Invalid authorization request URL."), "validateVerifierRequest");
-            return;
-        }
+        if (!cleanParams || cleanParams === '?') {
+            handleApiError(new Error("Invalid authorization request URL."), "validateVerifierRequest");
+            return;
+        }

201-210: Minor: Redundant visibility check.

CredentialRequestModal is conditionally rendered with && and also receives isVisible prop. The outer condition already guarantees the modal should be shown.

                 {showCredentialRequest && presentationIdData && (
                     <CredentialRequestModal
-                        isVisible={showCredentialRequest && !isErrorActive}
+                        isVisible={!isErrorActive}
                         verifierName={verifierData?.name || 'Verifier'}

51-66: State setters in dependency arrays are unnecessary.

React guarantees that state setter functions (like setVerifierData, setShowTrustVerifier) are stable and don't change between renders. Including them in dependency arrays is harmless but adds noise.

-    }, [setPresentationIdData, setVerifierData, setShowTrustVerifier, setShowCredentialRequest]);
+    }, []);

-    }, [setShowTrustVerifier, setShowCredentialRequest]);
+    }, []);

Also applies to: 100-104, 116-119

inji-web/src/components/Common/ToolTip/InfoTooltip.tsx (1)

43-47: Align alt text with aria-hidden on the icon

Since the icon is marked aria-hidden="true", screen readers will ignore it, so the alt="Information icon" text is unused. For clarity and conventional a11y practice, you can set an empty alt:

-                    alt="Information icon"
-                    aria-hidden="true"
+                    alt=""
+                    aria-hidden="true"

This keeps the icon purely decorative while making the intent explicit.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between aba679b and 86ea721.

⛔ Files ignored due to path filters (2)
  • inji-web/src/__tests__/components/Common/ToolTip/__snapshots__/InfoTooltip.test.tsx.snap is excluded by !**/*.snap
  • inji-web/src/__tests__/pages/__snapshots__/VPAuthorizationPage.test.tsx.snap is excluded by !**/*.snap
📒 Files selected for processing (24)
  • docs/OpenID4VPIntegrationGuide.md (1 hunks)
  • inji-web/src/Router.tsx (2 hunks)
  • inji-web/src/__tests__/components/Common/ToolTip/InfoTooltip.test.tsx (2 hunks)
  • inji-web/src/__tests__/components/Issuer/TrustVerifierModal.test.tsx (1 hunks)
  • inji-web/src/__tests__/handlers/CredentialShareHandler.test.tsx (1 hunks)
  • inji-web/src/__tests__/hooks/useApiErrorHandler.test.ts (1 hunks)
  • inji-web/src/__tests__/modals/CredentialRequestModal.test.tsx (1 hunks)
  • inji-web/src/__tests__/modals/LoaderModal.test.tsx (1 hunks)
  • inji-web/src/__tests__/pages/VPAuthorizationPage.test.tsx (6 hunks)
  • inji-web/src/__tests__/utils/errorHandling.test.ts (10 hunks)
  • inji-web/src/components/Common/ToolTip/InfoTooltip.tsx (1 hunks)
  • inji-web/src/components/Credentials/CredentialItem.tsx (2 hunks)
  • inji-web/src/components/Issuers/TrustVerifierModal.tsx (2 hunks)
  • inji-web/src/components/PageTemplate/PasscodePage/PasscodePageTemplate.tsx (1 hunks)
  • inji-web/src/handlers/CredentialShareHandler.tsx (3 hunks)
  • inji-web/src/hooks/useApiErrorHandler.ts (4 hunks)
  • inji-web/src/hooks/useInterceptor.ts (1 hunks)
  • inji-web/src/modals/CredentialRequestModal.tsx (4 hunks)
  • inji-web/src/modals/LoaderModal.tsx (1 hunks)
  • inji-web/src/modals/NoMatchingCredentialsModal.tsx (2 hunks)
  • inji-web/src/pages/User/Passcode/PasscodePage.tsx (1 hunks)
  • inji-web/src/pages/VPAuthorizationPage.tsx (1 hunks)
  • inji-web/src/types/components.d.ts (0 hunks)
  • inji-web/src/utils/errorHandling.ts (2 hunks)
💤 Files with no reviewable changes (1)
  • inji-web/src/types/components.d.ts
🧰 Additional context used
🧠 Learnings (5)
📚 Learning: 2025-11-11T13:34:35.642Z
Learnt from: kongadurgesh
Repo: mosip/inji-web PR: 454
File: inji-web/src/components/Issuers/TrustRejectionModal.tsx:43-51
Timestamp: 2025-11-11T13:34:35.642Z
Learning: In inji-web, the TrustRejectionModal component does not require additional local error handling or loading states for the handleConfirm callback. The error handling in rejectVerifierRequest (via withErrorHandling) is sufficient and has been tested for blocked scenarios.

Applied to files:

  • inji-web/src/modals/CredentialRequestModal.tsx
  • inji-web/src/__tests__/handlers/CredentialShareHandler.test.tsx
  • inji-web/src/handlers/CredentialShareHandler.tsx
  • inji-web/src/pages/VPAuthorizationPage.tsx
  • inji-web/src/modals/NoMatchingCredentialsModal.tsx
  • inji-web/src/__tests__/modals/CredentialRequestModal.test.tsx
  • inji-web/src/__tests__/components/Issuer/TrustVerifierModal.test.tsx
  • inji-web/src/components/Issuers/TrustVerifierModal.tsx
📚 Learning: 2025-10-22T13:49:57.892Z
Learnt from: kongadurgesh
Repo: mosip/inji-web PR: 442
File: inji-web/src/components/Credentials/PresentationCredentialList.tsx:37-37
Timestamp: 2025-10-22T13:49:57.892Z
Learning: In inji-web/src/components/Credentials/PresentationCredentialList.tsx, the format field is hardcoded as 'ldp_vc' because currently only ldp_vc credential format is supported. Other credential formats (like jwt) are planned for future scope.

Applied to files:

  • inji-web/src/modals/CredentialRequestModal.tsx
  • inji-web/src/handlers/CredentialShareHandler.tsx
  • inji-web/src/components/Credentials/CredentialItem.tsx
📚 Learning: 2025-10-16T09:49:00.207Z
Learnt from: kongadurgesh
Repo: mosip/inji-web PR: 438
File: inji-web/src/utils/api.ts:290-305
Timestamp: 2025-10-16T09:49:00.207Z
Learning: In the inji-web application, the Authorization page (UserAuthorizationPage) ensures users are redirected to login if walletId is missing. The walletId is guaranteed to exist in AppStorage (KEYS.WALLET_ID) during normal credential request flows.

Applied to files:

  • inji-web/src/hooks/useInterceptor.ts
  • docs/OpenID4VPIntegrationGuide.md
📚 Learning: 2025-11-10T06:31:44.815Z
Learnt from: Rudhhi-Shah-14
Repo: mosip/inji-web PR: 453
File: inji-web/src/pages/AuthorizationPage.tsx:22-25
Timestamp: 2025-11-10T06:31:44.815Z
Learning: In inji-web/src/pages/AuthorizationPage.tsx, the URL construction for redirecting to /user/authorize intentionally checks if window.location.search starts with '?' to avoid double question marks. A trailing '?' when window.location.search is empty is acceptable and doesn't affect behavior.

Applied to files:

  • inji-web/src/__tests__/pages/VPAuthorizationPage.test.tsx
  • inji-web/src/pages/VPAuthorizationPage.tsx
  • inji-web/src/Router.tsx
📚 Learning: 2025-11-11T04:37:04.453Z
Learnt from: kongadurgesh
Repo: mosip/inji-web PR: 454
File: inji-web/src/utils/verifierUtils.ts:47-48
Timestamp: 2025-11-11T04:37:04.453Z
Learning: In inji-web, the redirectUri used in verifierUtils.rejectVerifierRequest does not require frontend validation because it is already validated by the backend API (api.validateVerifierRequest) as part of the payload. The backend validation is considered sufficient for security.

Applied to files:

  • inji-web/src/modals/NoMatchingCredentialsModal.tsx
🧬 Code graph analysis (6)
inji-web/src/__tests__/pages/VPAuthorizationPage.test.tsx (1)
inji-web/src/pages/VPAuthorizationPage.tsx (1)
  • VPAuthorizationPage (18-250)
inji-web/src/pages/VPAuthorizationPage.tsx (5)
inji-web/src/types/components.d.ts (1)
  • PresentationCredential (119-124)
inji-web/src/hooks/useApi.ts (1)
  • useApi (28-156)
inji-web/src/hooks/User/useUser.tsx (1)
  • useUser (4-10)
inji-web/src/hooks/useApiErrorHandler.ts (1)
  • useApiErrorHandler (45-162)
inji-web/src/utils/constants.ts (2)
  • ROUTES (24-39)
  • OPENID4VP_AUTHORIZE_PREFIX (67-67)
inji-web/src/__tests__/utils/errorHandling.test.ts (1)
inji-web/src/utils/errorHandling.ts (4)
  • standardizeError (40-71)
  • ERROR_TYPES (18-28)
  • StandardError (6-9)
  • logError (76-93)
inji-web/src/components/Issuers/TrustVerifierModal.tsx (1)
inji-web/src/components/Common/ToolTip/InfoTooltip.tsx (1)
  • InfoTooltip (13-79)
inji-web/src/__tests__/components/Common/ToolTip/InfoTooltip.test.tsx (1)
inji-web/src/components/Common/ToolTip/InfoTooltip.tsx (1)
  • InfoTooltip (13-79)
inji-web/src/Router.tsx (2)
inji-web/src/utils/constants.ts (1)
  • Pages (8-21)
inji-web/src/pages/VPAuthorizationPage.tsx (1)
  • VPAuthorizationPage (18-250)
🪛 LanguageTool
docs/OpenID4VPIntegrationGuide.md

[style] ~15-~15: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...let (/authorize). 3. User logs in. 4. User reviews verifier details and gives cons...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~16-~16: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... verifier details and gives consent. 5. User selects an eligible credential matching...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: build-ui-test-local
  • GitHub Check: inji-web / build-dockers
  • GitHub Check: Analyze (java-kotlin)
🔇 Additional comments (36)
inji-web/src/hooks/useInterceptor.ts (1)

38-38: Good catch on the typo.

Minor grammar correction in the comment improves clarity. No behavioral changes.

docs/OpenID4VPIntegrationGuide.md (1)

294-300: Verify Mimoto endpoint accuracy.

The technical specification references several Mimoto endpoints (e.g., POST /wallets/{walletId}/presentations, PATCH /wallets/{walletId}/presentations/{presentationId}). Ensure these endpoints and their signatures match the actual Mimoto API implementation.

inji-web/src/pages/User/Passcode/PasscodePage.tsx (1)

291-299: Updated testId composition correctly mirrors previous behavior and new template API

Composing testId as passcode${testIdSuffix} (with testIdSuffix carrying the leading - only for lock states) preserves the old effective IDs ("passcode", "passcode-temporarily-locked", etc.) while matching the new PasscodePageTemplate single-testId API. No functional regressions evident here.

inji-web/src/components/Issuers/TrustVerifierModal.tsx (2)

5-5: LGTM! Component rename applied consistently.

The import and usage have been updated correctly to reflect the InfoTooltipTriggerInfoTooltip rename. The component interface remains unchanged.

Also applies to: 130-134


5-10: LGTM! Clean component and interface rename.

The rename from InfoTooltipTrigger to InfoTooltip is well-executed with no functional changes. The component interface and behavior remain identical.

Also applies to: 13-18

inji-web/src/__tests__/components/Common/ToolTip/InfoTooltip.test.tsx (1)

4-4: LGTM! Test references updated correctly.

The test file has been updated to import and render InfoTooltip instead of InfoTooltipTrigger. All test coverage is preserved.

Also applies to: 8-8, 17-17

inji-web/src/__tests__/components/Issuer/TrustVerifierModal.test.tsx (1)

62-68: LGTM! Mock updated to match renamed component.

The mock module path and export name have been correctly updated from InfoTooltipTrigger to InfoTooltip. The mock implementation remains functionally identical.

inji-web/src/components/Credentials/CredentialItem.tsx (1)

13-17: Inline memo export is clean and behavior‑preserving

Defining CredentialItem directly as a memo<CredentialItemProps>(...) export removes an extra component symbol without changing props, hooks, or render logic. Import surface stays the same (CredentialItem named export), so this is a safe, stylistic refactor aligned with the broader inline‑memo pattern in the PR.

Please just confirm TS/React build and tests pass after this refactor (no lingering references to any previous internal component name).

Also applies to: 120-120

inji-web/src/components/PageTemplate/PasscodePage/PasscodePageTemplate.tsx (1)

78-78: LGTM! Simplified test ID generation.

The refactoring to remove testIdSuffix and have the caller compose the complete testId simplifies the component API. According to the PR summary, PasscodePage.tsx has been updated accordingly.

Verify that all callers of PasscodePageTemplate have been updated to match the new API, particularly checking that:

  • No remaining usages pass a testIdSuffix prop
  • All test IDs are composed at the call site before passing to the component
inji-web/src/modals/LoaderModal.tsx (1)

64-64: LGTM! Cosmetic whitespace cleanup.

The removal of the trailing newline is a minor formatting improvement with no functional impact.

inji-web/src/__tests__/handlers/CredentialShareHandler.test.tsx (1)

15-18: LGTM! Test mock updated to align with component rename.

The mock correctly reflects the LoadingModal → LoaderModal refactoring while preserving the test behavior.

inji-web/src/modals/NoMatchingCredentialsModal.tsx (1)

49-88: LGTM! Callback naming standardization.

The rename from rejectVerifierCore to rejectVerifierCallback improves naming consistency across the codebase. All references and dependencies are correctly updated with no logic changes.

inji-web/src/__tests__/hooks/useApiErrorHandler.test.ts (1)

196-196: LGTM! Test updated for hook API change.

The test correctly uses the renamed errorCodesToRetry property, aligning with the updated useApiErrorHandler hook API.

inji-web/src/__tests__/modals/LoaderModal.test.tsx (1)

3-3: LGTM! Import path updated for renamed component.

The import correctly targets the LoaderModal component, consistent with the codebase-wide refactoring.

inji-web/src/__tests__/pages/VPAuthorizationPage.test.tsx (3)

5-5: LGTM! Component rename to VPAuthorizationPage.

The import reflects the page component rename from UserAuthorizationPage to VPAuthorizationPage, providing more descriptive naming (VP = Verifiable Presentation).


83-88: LGTM! Mock updated to LoaderModal.

The mock correctly targets LoaderModal instead of LoadingModal, consistent with the codebase-wide component rename.


247-247: LGTM! Test suite updated for component rename.

All test references consistently updated from UserAuthorizationPage to VPAuthorizationPage, including renders, rerenders, and test suite description.

Also applies to: 288-288, 442-442, 534-534

inji-web/src/__tests__/modals/CredentialRequestModal.test.tsx (1)

85-93: LGTM! Test mock updated for component rename.

The mock correctly reflects the LoadingModal → LoaderModal refactoring while maintaining identical test behavior.

inji-web/src/modals/CredentialRequestModal.tsx (2)

4-4: LGTM! Import updated to LoaderModal.

The import correctly reflects the LoadingModal → LoaderModal component rename, consistent with the codebase-wide refactoring.


108-132: LGTM! Callback naming standardization.

The rename from fetchCredentialsCore to fetchCredentialsCallback improves naming consistency. All function calls, error handler references, and dependency arrays are correctly updated with no logic changes.

inji-web/src/Router.tsx (1)

14-14: LGTM! Route correctly updated to use VPAuthorizationPage for authenticated user flow.

The routing change properly separates the authorization flows:

  • Non-user route (/authorize) continues to use AuthorizationPage
  • User route (/user/authorize) now uses VPAuthorizationPage for the OpenID4VP flow

Also applies to: 132-132

inji-web/src/handlers/CredentialShareHandler.tsx (2)

5-5: LGTM! Import path updated to match renamed modal component.


42-51: LGTM! Callback rename improves consistency.

The rename from submitPresentationCore to submitPresentationCallback aligns with the naming convention used in other parts of the codebase (e.g., validateVerifierRequestCallback in VPAuthorizationPage). Dependency array correctly updated.

Also applies to: 57-79

inji-web/src/hooks/useApiErrorHandler.ts (1)

10-12: LGTM! Configuration field rename is consistent throughout.

The rename from retryableErrorCodes to errorCodesToRetry is applied consistently across the interface definition, destructuring, usage, and dependency array.

Also applies to: 50-52, 87-87, 119-119

inji-web/src/__tests__/utils/errorHandling.test.ts (4)

7-7: LGTM! Import updated to match renamed type.


72-72: LGTM! Test assertions updated to validate simplified StandardError structure.

The tests now correctly assert originalError preservation rather than generated messages, aligning with the updated StandardError interface that contains only code and originalError.

Also applies to: 94-94, 115-116, 126-127, 137-138, 146-147


149-174: LGTM! Comprehensive HTTP status code mapping tests.

Good coverage of:

  • Specific status code mappings (400, 401, 404, 500)
  • Fallback behavior for unmapped 4xx → API_CLIENT
  • Fallback behavior for unmapped 5xx → API_SERVER
  • Original error preservation

Also applies to: 176-188


191-240: LGTM! Updated logError and withErrorHandling tests.

Tests correctly use originalError in StandardError construction and validate error propagation through withErrorHandling.

Also applies to: 262-263

inji-web/src/pages/VPAuthorizationPage.tsx (3)

1-16: LGTM! Well-organized imports.

All necessary dependencies are imported for the VP authorization flow including modals, handlers, hooks, and navigation utilities.


171-249: LGTM! Well-structured modal orchestration.

The conditional rendering of modals based on state is well organized:

  • LoaderModal for loading/retrying states
  • TrustVerifierModal for untrusted verifiers
  • CredentialRequestModal for credential selection
  • CredentialShareHandler for submission
  • ErrorCard for error display
  • TrustRejectionModal for cancellation confirmation

The isErrorActive flag correctly prevents other modals from showing during error states. Based on learnings, the TrustRejectionModal error handling via withErrorHandling is sufficient.


159-167: Verify the useEffect dependency array for isUserLoggedIn.

The isUserLoggedIn function reference from useUser() is used in the dependency array, but it's unclear whether this function reference is stable across renders. If useUser returns a new function reference on each render, this effect won't behave as expected. Additionally, loadInitialData is excluded via ESLint disable. Confirm whether isUserLoggedIn is memoized in the useUser hook and whether loadInitialData should be included in the dependency array.

inji-web/src/utils/errorHandling.ts (4)

11-15: LGTM!

The renamed ErrorOptions interface is cleaner and the optional fields are well-structured for flexible error handling configuration.


40-71: LGTM!

The simplified return structure is clean. The fallback categorization for unmapped HTTP statuses (4xx → API_CLIENT, 5xx → API_SERVER) ensures robustness.


76-93: LGTM!

The message extraction chain provides sensible fallbacks, and computing the message at log time rather than embedding it in the error object is a good separation of concerns. The ISO timestamp format is appropriate for log correlation.


98-110: LGTM!

The async wrapper maintains a clean pattern for standardized error handling with proper logging integration.

inji-web/src/components/Common/ToolTip/InfoTooltip.tsx (1)

5-10: Props interface rename looks consistent

The InfoTooltipProps interface matches how the component is used; prop names and optional fields align and keep the API clear. No issues here.

@jackjain jackjain merged commit 2fb6d68 into inji:develop Dec 2, 2025
13 checks passed
@jackjain jackjain deleted the injiweb-1795-sync-release-to-develop branch December 2, 2025 07:33
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.

3 participants