Android Match SDK source code#9
Merged
Merged
Conversation
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
B Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
|
Warning Review limit reached
More reviews will be available in 39 minutes and 21 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThis PR introduces a complete Android biometric Match SDK from scratch. It adds Gradle wrapper scripts, root and module build files, a CI workflow that assembles and uploads the AAR, a boilerplate ChangesProject infrastructure and app scaffold
Match SDK library contracts and validation
Service implementations and format conversion
Test coverage
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 19
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
gradlew.bat (1)
1-90:⚠️ Potential issue | 🟠 Major | ⚡ Quick winConvert this batch script to CRLF line endings.
gradlew.batcommitted with LF-only endings can cause parsing/GOTO issues in Windows cmd environments.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@gradlew.bat` around lines 1 - 90, The gradlew.bat file is currently using LF-only line endings, which causes parsing and GOTO command issues in Windows cmd environments. Convert the entire gradlew.bat file from LF line endings to CRLF (Carriage Return + Line Feed) line endings. This can be done by configuring your editor or IDE to save the file with CRLF line endings, or by using git commands to normalize the line endings for this Windows batch script file.Source: Linters/SAST tools
🟡 Minor comments (2)
matchsdk/src/main/java/io/mosip/mock/sdk/impl/SampleSDK.java-71-73 (1)
71-73:⚠️ Potential issue | 🟡 Minor
convertFormat(...)silently returns the input unchanged, ignoring format conversion parameters.The method ignores
sourceFormat,targetFormat,sourceParams,targetParams, andmodalitiesToConvert, returningsampleunchanged. Callers using this method cannot distinguish whether conversion succeeded or failed. Consider delegating toconvertFormatV2(...)to provide error handling via the Response wrapper, or clarify in documentation that this method is intentionally a no-op.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@matchsdk/src/main/java/io/mosip/mock/sdk/impl/SampleSDK.java` around lines 71 - 73, The convertFormat method in SampleSDK class currently ignores all conversion parameters (sourceFormat, targetFormat, sourceParams, targetParams, and modalitiesToConvert) and silently returns the input sample unchanged without any error indication. To fix this, either delegate the implementation to the convertFormatV2 method which provides proper error handling through a Response wrapper, or add clear documentation explicitly stating that this is an intentional no-op method. Ensure that callers can distinguish between successful conversion and failed/unsupported conversion scenarios.matchsdk/src/main/java/io/mosip/mock/sdk/constant/TargetFormatCode.java-9-12 (1)
9-12:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix incorrect modality wording in target format messages.
Line [9] and Line [12] describe face conversions as “to Finger ISO format”, which is inconsistent with
ISO19794_5_2011_*face format constants. This will mislead downstream diagnostics/error surfaces.Suggested patch
- ISO19794_5_2011_JPEG("ISO19794_5_2011/JPEG", "Face ISO format to Finger ISO format with JPEG IMAGE"), + ISO19794_5_2011_JPEG("ISO19794_5_2011/JPEG", "Face ISO format to Face ISO format with JPEG IMAGE"), ... - ISO19794_5_2011_PNG("ISO19794_5_2011/PNG", "Face ISO format to Finger ISO format with PNG IMAGE"), + ISO19794_5_2011_PNG("ISO19794_5_2011/PNG", "Face ISO format to Face ISO format with PNG IMAGE"),🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@matchsdk/src/main/java/io/mosip/mock/sdk/constant/TargetFormatCode.java` around lines 9 - 12, The description strings for the ISO19794_5_2011_JPEG and ISO19794_5_2011_PNG enum constants in the TargetFormatCode class incorrectly state "Face ISO format to Finger ISO format". Since ISO19794_5 represents face format, these descriptions should say "Face ISO format to Face ISO format" instead of "to Finger ISO format". Update both description strings to correctly reflect that these are face-to-face format conversions with different encoding (JPEG and PNG respectively).
🧹 Nitpick comments (10)
app/src/main/AndroidManifest.xml (1)
1-16: 💤 Low valueAll resource references resolve correctly; consider adding explicit
packageattribute for clarity.Cross-file verification confirms all referenced resources exist:
@string/app_name→app/src/main/res/values/strings.xmldefines "Match SDK"@style/Theme.MatchSDK→app/src/main/res/values/themes.xmldefines the theme@mipmap/ic_launcherand@mipmap/ic_launcher_round→ corresponding icon files added in this PR@xml/data_extraction_rulesand@xml/backup_rules→ backup/extraction rule files existThe manifest lacks a
packageattribute. With AGP 7.0+ andnamespacedefined inbuild.gradle, the package attribute is optional, but explicitly declaring it improves readability and forward compatibility with older tooling.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/src/main/AndroidManifest.xml` around lines 1 - 16, The `<manifest>` element in the AndroidManifest.xml file is missing an explicit `package` attribute. Although the package is implicitly defined via the `namespace` in build.gradle with AGP 7.0+, add the `package` attribute directly to the `<manifest>` opening tag to improve readability and ensure forward compatibility with older tooling. The package attribute value should match your application's package name (e.g., com.example.matchsdk).app/build.gradle (1)
1-37: ⚡ Quick winConsider updating SDK and dependency versions for current toolchain compatibility.
The
app/build.gradleuses SDK level 31 (Android 12, released 2021) and dependencies from early 2022, which are significantly outdated for a project created in 2026. For example,appcompat:1.4.1is ~4 years old; current is 1.7.x+. Similarly,gradle/wrapper/gradle-wrapper.propertiesshows Gradle 7.5 (~4 years old); current is 8.x+.While this may be intentional for backward-compatibility testing of a mock SDK, updating to current versions would improve security (fixing known CVEs in older libraries), performance, and API coverage. If older versions are required, document the rationale.
[maintenance_and_code_quality]
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/build.gradle` around lines 1 - 37, The app/build.gradle file uses outdated SDK levels and dependency versions that are several years old and no longer aligned with current toolchain standards. Update the compileSdk and targetSdk values (currently set to 31) to a more recent level (e.g., 34 or higher), and update the dependency versions for androidx.appcompat:appcompat, com.google.android.material:material, androidx.test.ext:junit, and androidx.test.espresso:espresso-core to their current releases. Alternatively, if maintaining these older versions is intentional for backward-compatibility testing purposes, add explanatory comments in the file documenting that rationale to clarify the decision to reviewers.matchsdk/src/main/java/io/mosip/mock/sdk/service/SDKInfoService.java (1)
35-39: ⚡ Quick winAvoid sharing one mutable modalities list across all supported methods.
All four map entries point to the same
supportedModalitiesinstance. If any consumer mutates one entry’s list, all methods change together. Create per-entry copies (or immutable lists) when populatingsupportedMethods.Suggested change
- Map<BiometricFunction, List<BiometricType>> supportedMethods = new HashMap<>(); - supportedMethods.put(BiometricFunction.MATCH, supportedModalities); - supportedMethods.put(BiometricFunction.QUALITY_CHECK, supportedModalities); - supportedMethods.put(BiometricFunction.EXTRACT, supportedModalities); - supportedMethods.put(BiometricFunction.CONVERT_FORMAT, supportedModalities); + Map<BiometricFunction, List<BiometricType>> supportedMethods = new HashMap<>(); + supportedMethods.put(BiometricFunction.MATCH, new ArrayList<>(supportedModalities)); + supportedMethods.put(BiometricFunction.QUALITY_CHECK, new ArrayList<>(supportedModalities)); + supportedMethods.put(BiometricFunction.EXTRACT, new ArrayList<>(supportedModalities)); + supportedMethods.put(BiometricFunction.CONVERT_FORMAT, new ArrayList<>(supportedModalities));🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@matchsdk/src/main/java/io/mosip/mock/sdk/service/SDKInfoService.java` around lines 35 - 39, The `supportedMethods` map is storing the same `supportedModalities` list reference for all four BiometricFunction entries (MATCH, QUALITY_CHECK, EXTRACT, CONVERT_FORMAT). If this list is mutated by any consumer, all four methods will be affected. Fix this by creating a new copy of the `supportedModalities` list for each put() call to `supportedMethods`, or alternatively wrap each entry with Collections.unmodifiableList() to create immutable copies. This ensures each BiometricFunction has its own independent list instance.matchsdk/src/main/java/io/mosip/mock/sdk/constant/ParameterCode.java (1)
20-27: ⚡ Quick winUnify invalid-code behavior with the other enum contracts.
fromCodereturningnullon Line [26] diverges from the explicit-fail behavior used inSourceFormatCode.fromCode(...)andTargetFormatCode.fromCode(...). Prefer throwing a typed exception here too, to avoid silent null propagation.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@matchsdk/src/main/java/io/mosip/mock/sdk/constant/ParameterCode.java` around lines 20 - 27, The fromCode method in ParameterCode currently returns null when no matching code is found, which diverges from the consistent behavior in SourceFormatCode.fromCode(...) and TargetFormatCode.fromCode(...) that throw typed exceptions instead. Replace the null return statement at the end of the fromCode method with a throw statement that raises an appropriate exception (such as IllegalArgumentException) with a descriptive error message indicating that the provided code name is invalid. This ensures consistent error handling across all enum contracts and prevents silent null propagation.matchsdk/src/main/java/io/mosip/mock/sdk/constant/SdkConstant.java (1)
3-5: ⚡ Quick winMake SDK constant immutable and prevent class instantiation.
On Line [4],
SDK_CHECK_ISO_TIMESTAMP_FORMATis mutable (public static String). This should bepublic static finalin a non-instantiable constants class.Suggested patch
-public class SdkConstant { - public static String SDK_CHECK_ISO_TIMESTAMP_FORMAT = "sdk_check_iso_timestamp_format"; +public final class SdkConstant { + private SdkConstant() {} + public static final String SDK_CHECK_ISO_TIMESTAMP_FORMAT = "sdk_check_iso_timestamp_format"; }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@matchsdk/src/main/java/io/mosip/mock/sdk/constant/SdkConstant.java` around lines 3 - 5, The field SDK_CHECK_ISO_TIMESTAMP_FORMAT in the SdkConstant class is mutable and should be declared as final to make it truly constant. Additionally, the SdkConstant class should be non-instantiable by adding a private constructor. To fix this, add the final keyword to the SDK_CHECK_ISO_TIMESTAMP_FORMAT field declaration (changing public static String to public static final String), and add a private no-argument constructor to the SdkConstant class to prevent instantiation of what should be a constants utility class.matchsdk/src/main/java/io/mosip/mock/sdk/util/Util.java (2)
24-30: 💤 Low valueMinor: redundant array copy when
metaDatais null.
ArrayUtils.addAll(data)creates a defensive copy even when no metadata is appended. You can passdatadirectly tosha256Hexin this case.♻️ Optional simplification
- byte[] combinedPlainTextBytes; - if (metaData == null) { - combinedPlainTextBytes = ArrayUtils.addAll(data); - } else { - combinedPlainTextBytes = ArrayUtils.addAll(data, metaData.getBytes(StandardCharsets.UTF_8)); - } - return DigestUtils.sha256Hex(combinedPlainTextBytes); + if (metaData == null) { + return DigestUtils.sha256Hex(data); + } + byte[] combinedPlainTextBytes = ArrayUtils.addAll(data, metaData.getBytes(StandardCharsets.UTF_8)); + return DigestUtils.sha256Hex(combinedPlainTextBytes);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@matchsdk/src/main/java/io/mosip/mock/sdk/util/Util.java` around lines 24 - 30, The condition in the if-else block for handling null metaData is creating a redundant array copy. When metaData is null, avoid the unnecessary call to ArrayUtils.addAll(data) and instead pass the data array directly to DigestUtils.sha256Hex(). Simplify the logic so that when metaData is null, you call DigestUtils.sha256Hex(data) directly, and when metaData is not null, keep the current logic that combines the arrays using ArrayUtils.addAll(data, metaData.getBytes(StandardCharsets.UTF_8)).
11-18: 💤 Low value
throws NoSuchAlgorithmExceptionis never thrown.
DigestUtils.sha256Hexhandles the algorithm lookup internally and does not propagateNoSuchAlgorithmException. Declaring it forces callers to handle an exception that cannot occur, which is misleading.Consider removing the
throwsclause from both methods if you want a cleaner API, or keep it for forward compatibility if you anticipate switching to rawMessageDigestlater.Also applies to: 20-31
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@matchsdk/src/main/java/io/mosip/mock/sdk/util/Util.java` around lines 11 - 18, The compareHash method declares throws NoSuchAlgorithmException but the underlying DigestUtils.sha256Hex handles exception checking internally and never propagates this exception, making the declaration misleading to callers. Remove the throws NoSuchAlgorithmException clause from the compareHash method signature. Apply the same fix to the computeFingerPrint method (which also declares the same throws clause) - remove throws NoSuchAlgorithmException from its signature as well since it also uses DigestUtils internally and never actually throws this exception.matchsdk/src/test/java/io/mosip/mock/sdk/UtilTest.java (1)
33-46: ⚡ Quick winConsider adding edge-case tests for
compareHashwith null/empty inputs.
Util.compareHashreturnsfalsewhen either input is null or empty (lines 12-14 in Util.java). SinceMatchServicerelies on this behavior to determine match/no-match outcomes (per context snippet), adding explicit tests for these edge cases would strengthen coverage.💚 Suggested tests
`@Test` public void compareHash_nullFirstArray_returnsFalse() throws NoSuchAlgorithmException { byte[] data = "sample".getBytes(StandardCharsets.UTF_8); Assert.assertFalse(Util.compareHash(null, data)); } `@Test` public void compareHash_nullSecondArray_returnsFalse() throws NoSuchAlgorithmException { byte[] data = "sample".getBytes(StandardCharsets.UTF_8); Assert.assertFalse(Util.compareHash(data, null)); } `@Test` public void compareHash_emptyFirstArray_returnsFalse() throws NoSuchAlgorithmException { byte[] data = "sample".getBytes(StandardCharsets.UTF_8); Assert.assertFalse(Util.compareHash(new byte[0], data)); }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@matchsdk/src/test/java/io/mosip/mock/sdk/UtilTest.java` around lines 33 - 46, The UtilTest class lacks edge-case tests for the Util.compareHash method's null and empty input handling. Add three new test methods to UtilTest: compareHash_nullFirstArray_returnsFalse to verify compareHash returns false when the first parameter is null, compareHash_nullSecondArray_returnsFalse to verify it returns false when the second parameter is null, and compareHash_emptyFirstArray_returnsFalse to verify it returns false when the first array is empty. Each test should follow the same pattern as the existing compareHash test methods by creating appropriate test data, calling Util.compareHash with the edge-case inputs, and asserting the expected false result.matchsdk/src/test/java/io/mosip/mock/sdk/SDKServiceTest.java (1)
433-438: ⚡ Quick winThis coverage test is non-deterministic and under-asserted.
checkQuality_compoundFingerSubtype_coversSize2Branchcurrently validates only non-null response, so status regressions won’t fail the test. Assert an expected status (or explicit allowed set) to keep branch coverage meaningful.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@matchsdk/src/test/java/io/mosip/mock/sdk/SDKServiceTest.java` around lines 433 - 438, The test method checkQuality_compoundFingerSubtype_coversSize2Branch currently only asserts that the response is not null, which is insufficient for meaningful branch coverage validation. Replace the non-deterministic assertion with explicit validation of the expected response status. Based on the comment in the code indicating the result should be either INVALID_INPUT (when ISO fails) or SUCCESS depending on the data, assert that the response status matches one of these expected values. This ensures the test will catch any unexpected status regressions in the checkQuality method.matchsdk/src/test/java/io/mosip/mock/sdk/MatchSDKTest.java (1)
743-744: ⚡ Quick winHarden XML parser configuration in test helpers to prevent XXE. Both helpers construct
DocumentBuilderFactorywith default settings and parse XML directly, which keeps external entity resolution enabled unless explicitly disabled.
matchsdk/src/test/java/io/mosip/mock/sdk/MatchSDKTest.java#L743-L744: configure secure-processing and disable DTD/external entities before creating the builder.matchsdk/src/test/java/io/mosip/mock/sdk/SampleSDKTest.java#L399-L400: apply the same hardened factory configuration to keep parser behavior consistent and safe.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@matchsdk/src/test/java/io/mosip/mock/sdk/MatchSDKTest.java` around lines 743 - 744, The DocumentBuilderFactory instances in both test files are created with default settings that leave XXE (XML External Entity) processing enabled. Fix this by configuring the DocumentBuilderFactory to disable external entity resolution and enable secure processing before calling newDocumentBuilder(). Specifically, at matchsdk/src/test/java/io/mosip/mock/sdk/MatchSDKTest.java lines 743-744, add factory configuration calls between creating the DocumentBuilderFactory instance and calling newDocumentBuilder() to disable DTD processing and external entities. Apply the identical hardened factory configuration at matchsdk/src/test/java/io/mosip/mock/sdk/SampleSDKTest.java lines 399-400 to ensure consistent secure parsing behavior across both test files.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build.yml:
- Around line 4-7: The `branches` filter under the `workflow_dispatch` event is
ineffective and will be silently ignored because the `workflow_dispatch` trigger
does not support branch filtering in GitHub Actions. Remove the entire
`branches` section (including the entries for `release*` and `develop`) that
appears under `workflow_dispatch`, keeping only the `workflow_dispatch:` trigger
itself. The branch filtering logic is already correctly implemented in the
`push` and `pull_request` events above, which do support branch filtering.
- Around line 24-40: Replace the mutable action version tags with full commit
SHAs for all three third-party actions: actions/checkout@v4,
actions/setup-java@v4, and actions/upload-artifact@v4. For the checkout action
specifically, also add a persist-credentials: false parameter under its with
block to prevent the checkout token from being accessible to subsequent steps,
since this workflow does not perform authenticated Git operations. This hardens
the workflow against supply chain attacks by pinning actions to specific
immutable commits rather than relying on mutable version tags that could be
updated by compromised repositories.
In `@gradle/wrapper/gradle-wrapper.properties`:
- Around line 4-6: The gradle-wrapper.properties file is missing the
distributionSha256Sum property, which is required to verify the integrity of the
downloaded Gradle distribution. Add the distributionSha256Sum property with the
correct checksum value for gradle-7.5-all.zip to ensure supply-chain security
during CI and local bootstrap. The checksum should be the SHA-256 hash of the
gradle-7.5-all.zip distribution file from the official Gradle repository.
In `@matchsdk/src/main/java/io/mosip/mock/sdk/exception/SDKException.java`:
- Around line 21-24: The 2-arg constructor SDKException(String errorCode, String
errorMessage) at lines 21–24 passes only errorMessage to super() and then calls
addInfo() to handle the errorCode separately, which differs from the 3-arg
constructor that passes both errorCode and errorMessage directly to super().
Align the 2-arg constructor by changing super(errorMessage) to super(errorCode,
errorMessage) to match the 3-arg constructor pattern and ensure consistent
base-exception initialization across both constructor paths. Remove the separate
addInfo() call after the super() invocation.
In `@matchsdk/src/main/java/io/mosip/mock/sdk/service/ConvertFormatService.java`:
- Around line 52-53: The sample parameter is being dereferenced at the line
containing the for loop with sample.getSegments() without first checking if
sample is null, causing a NullPointerException to be caught by the generic
Exception handler and returning UNKNOWN_ERROR instead of MISSING_INPUT. Add a
null check for the sample parameter before the for loop that iterates over
sample.getSegments(), and if sample is null, return the MISSING_INPUT error
status immediately to properly distinguish this validation failure from other
errors.
- Around line 67-74: The current key construction using only bioType and
bioSubType causes segments with identical modality and subtype to be merged,
losing data integrity when multiple distinct segments exist. Modify the key
generation to include segment-specific information (such as segment index or
position) to uniquely identify each segment, ensuring that the containsKey check
and values.put operations properly preserve distinct segments even when they
share the same bioType and bioSubType. This fix is needed in both the initial
segment processing block (around line 67-74 where the key is constructed and
values.put is called with encodeToURLSafeBase64) and the secondary processing
block (around line 94-103 where the same keying and deduplication logic is
applied).
- Around line 69-70: The ConvertFormatService accepts modalitiesToConvert in its
constructor but does not enforce it during conversion. The filter conditions at
line 69-70 and line 96-97 only check isValidBioTypeForSourceFormat without
verifying whether the bioType is present in the modalitiesToConvert list. Update
both filter conditions to additionally verify that the current bioType is
contained within the modalitiesToConvert collection before proceeding with
conversion, ensuring that only explicitly requested modalities are processed.
- Around line 99-101: The code at line 100 in ConvertFormatService.java calls
segment.getBirInfo().setPayload() without null-checking the result of
getBirInfo(), which can cause a NullPointerException if BirInfo is absent from
the segment. Add a null check to verify that getBirInfo() returns a non-null
value before attempting to call setPayload(segment.getBdb()) on it. This guard
should wrap the payload assignment to ensure the conversion flow handles
segments with missing BirInfo gracefully.
In
`@matchsdk/src/main/java/io/mosip/mock/sdk/service/ExtractTemplateService.java`:
- Around line 45-68: The for loop iterating over sample.getSegments() processes
every segment without checking if that segment's modality is in the
modalitiesToExtract parameter, causing unintended mutations of segments the
caller did not request. Add a check after validating the segment with
isValidBirData to verify that the segment's modality is present in the
modalitiesToExtract collection before performing any mutations such as
setPayload, setLevel, or setType. If the segment's modality is not in
modalitiesToExtract, skip processing that segment using continue.
In
`@matchsdk/src/main/java/io/mosip/mock/sdk/service/impl/ConverterServiceImpl.java`:
- Around line 37-43: Add null validation at the beginning of the convert method
in ConverterServiceImpl before using the input parameters. Specifically, check
if values, sourceFormat, and targetFormat are null before line 43 where
values.entrySet() is called and before line 53 where the switch statement uses
sourceCode. If any of these parameters are null, throw a ConversionException
with an appropriate error code instead of allowing NullPointerException to be
thrown during the entrySet() call or enum conversion.
In `@matchsdk/src/main/java/io/mosip/mock/sdk/service/MatchService.java`:
- Around line 95-101: The code allocates a MatchDecision array using
gallery.length without first validating that the gallery parameter is not null,
which can cause a NullPointerException. Add null validation checks for both
sample and gallery parameters before line 95 where the MatchDecision array is
created and before the getBioSegmentMap method calls are made. If either
parameter is null or empty, handle it appropriately by returning an error
response or throwing an SDKException with a descriptive message.
- Around line 185-191: The code dereferences nested objects from galleryBIR
(getBdbInfo().getSubtype().get(0)) without null-safety validation, creating NPE
risks with partial or invalid records. At the log statement in MatchService.java
around lines 185-191 where galleryBIR subtype is accessed in the LOGGER.info
call and the comparison statement, and similarly at lines 291-299, add
null-safety checks to validate that getBdbInfo() is not null, getSubtype()
returns a non-empty list before calling get(0). Consider extracting a helper
method to safely retrieve the subtype value with appropriate null checks and
fallback handling, then use this method consistently at both affected locations
to prevent NPE from reaching production with partial BIR data.
- Around line 104-116: The Decision object is instantiated once before the loop
that iterates over sampleBioSegmentMap.keySet() and is being reused across
iterations, causing mutations in exception handling to overwrite previous
modality results. Additionally, calling decision.getErrors().add() without
null-safety can fail if the errors list is null. Move the Decision object
instantiation inside the for loop so that each modality gets a fresh Decision
instance, and add a null-check before calling decision.getErrors().add() or
ensure the errors list is initialized when setting an error. This ensures each
modality comparison result is isolated and prevents data corruption from shared
state across iterations.
In `@matchsdk/src/main/java/io/mosip/mock/sdk/service/SDKService.java`:
- Around line 69-73: The code dereferences BIR segment entries without null
checks in the for loop iterating over record.getSegments() and also when
accessing bir variables at the other affected location. Add a null check for
segment before calling segment.getBdbInfo() in the for loop, and add a
corresponding null check for bir at lines 89-95 before dereferencing it. This
prevents NullPointerException when null entries exist in the segments collection
and ensures proper error handling through the SDKException status mapping path.
In `@matchsdk/src/main/java/io/mosip/mock/sdk/service/SegmentService.java`:
- Around line 24-31: The `getSegmentInfo()` method currently returns a hardcoded
success response with null segments, ignoring input parameters and providing
unusable output. Replace the null segment assignment with actual segmentation
logic that processes the sample and modalitiesToSegment parameters to generate
meaningful segment data. Only return a success status code after successfully
populating the segments in the BiometricRecord, or return an appropriate error
status if segmentation fails.
In `@matchsdk/src/test/java/io/mosip/mock/sdk/MatchSDKTest.java`:
- Around line 563-569: The test method
match_galleryFingerWithNullSubtypeElement_coversNpeCatch is named to cover NPE
handling but only asserts the response status code is 200, without verifying the
actual error result. After the Assert.assertEquals for status code 200, add an
additional assertion to verify that the modality decision in the response array
is Match.ERROR to properly validate the intended error branch behavior when a
null subtype element is encountered.
- Around line 83-89: The if-guard pattern in the test method at lines 83-89
allows the test to silently pass when response or response.getResponse() are
null, which hides failures. Replace the conditional guard with explicit
assertions that verify response and response.getResponse() are not null before
proceeding. Use Assert.assertNotNull() for the response object and
Assert.assertNotNull() for response.getResponse() to ensure the test fails
properly if the match call does not return the expected payload structure, then
move the for-loop and decision verification logic outside the guard to execute
only after these assertions pass.
In `@matchsdk/src/test/java/io/mosip/mock/sdk/SampleSDKTest.java`:
- Around line 263-265: The catch blocks in SampleSDKTest.java that catch and
swallow Throwable exceptions mask real test failures by silently ignoring all
throwables including assertions and runtime errors. Instead of empty catch
blocks that allow tests to pass, these exception handlers should use JUnit
assumptions or skip markers (such as Assume.assumeTrue() or similar test
framework mechanisms) to properly skip the test when the JVM-only environment
condition is not met. This way, real failures within the CommonUtil static
initializer or other code paths will not be hidden. Apply this fix to all
similar catch-Throwable blocks in the class that are catching this exception for
environment compatibility reasons.
In `@matchsdk/src/test/java/io/mosip/mock/sdk/ServiceCoverageTest.java`:
- Around line 461-497: The tests match_isValidBirDataFalse_finger_errorDecision,
match_isValidBirDataFalse_iris_errorDecision, and
match_isValidBirDataFalse_face_errorDecision (and similar tests in the 636-661
range) only assert that ResponseStatus.SUCCESS is returned, but they do not
validate the actual MatchDecision values in the response payload. Add assertions
to verify that the MatchDecision array in the response contains the expected
decision values (Match.ERROR for errorDecision tests, Match.NOT_MATCHED for
notMatched tests). Extract the MatchDecision objects from the response payload
and assert their decision field matches the expected outcome that the test name
indicates.
---
Outside diff comments:
In `@gradlew.bat`:
- Around line 1-90: The gradlew.bat file is currently using LF-only line
endings, which causes parsing and GOTO command issues in Windows cmd
environments. Convert the entire gradlew.bat file from LF line endings to CRLF
(Carriage Return + Line Feed) line endings. This can be done by configuring your
editor or IDE to save the file with CRLF line endings, or by using git commands
to normalize the line endings for this Windows batch script file.
---
Minor comments:
In `@matchsdk/src/main/java/io/mosip/mock/sdk/constant/TargetFormatCode.java`:
- Around line 9-12: The description strings for the ISO19794_5_2011_JPEG and
ISO19794_5_2011_PNG enum constants in the TargetFormatCode class incorrectly
state "Face ISO format to Finger ISO format". Since ISO19794_5 represents face
format, these descriptions should say "Face ISO format to Face ISO format"
instead of "to Finger ISO format". Update both description strings to correctly
reflect that these are face-to-face format conversions with different encoding
(JPEG and PNG respectively).
In `@matchsdk/src/main/java/io/mosip/mock/sdk/impl/SampleSDK.java`:
- Around line 71-73: The convertFormat method in SampleSDK class currently
ignores all conversion parameters (sourceFormat, targetFormat, sourceParams,
targetParams, and modalitiesToConvert) and silently returns the input sample
unchanged without any error indication. To fix this, either delegate the
implementation to the convertFormatV2 method which provides proper error
handling through a Response wrapper, or add clear documentation explicitly
stating that this is an intentional no-op method. Ensure that callers can
distinguish between successful conversion and failed/unsupported conversion
scenarios.
---
Nitpick comments:
In `@app/build.gradle`:
- Around line 1-37: The app/build.gradle file uses outdated SDK levels and
dependency versions that are several years old and no longer aligned with
current toolchain standards. Update the compileSdk and targetSdk values
(currently set to 31) to a more recent level (e.g., 34 or higher), and update
the dependency versions for androidx.appcompat:appcompat,
com.google.android.material:material, androidx.test.ext:junit, and
androidx.test.espresso:espresso-core to their current releases. Alternatively,
if maintaining these older versions is intentional for backward-compatibility
testing purposes, add explanatory comments in the file documenting that
rationale to clarify the decision to reviewers.
In `@app/src/main/AndroidManifest.xml`:
- Around line 1-16: The `<manifest>` element in the AndroidManifest.xml file is
missing an explicit `package` attribute. Although the package is implicitly
defined via the `namespace` in build.gradle with AGP 7.0+, add the `package`
attribute directly to the `<manifest>` opening tag to improve readability and
ensure forward compatibility with older tooling. The package attribute value
should match your application's package name (e.g., com.example.matchsdk).
In `@matchsdk/src/main/java/io/mosip/mock/sdk/constant/ParameterCode.java`:
- Around line 20-27: The fromCode method in ParameterCode currently returns null
when no matching code is found, which diverges from the consistent behavior in
SourceFormatCode.fromCode(...) and TargetFormatCode.fromCode(...) that throw
typed exceptions instead. Replace the null return statement at the end of the
fromCode method with a throw statement that raises an appropriate exception
(such as IllegalArgumentException) with a descriptive error message indicating
that the provided code name is invalid. This ensures consistent error handling
across all enum contracts and prevents silent null propagation.
In `@matchsdk/src/main/java/io/mosip/mock/sdk/constant/SdkConstant.java`:
- Around line 3-5: The field SDK_CHECK_ISO_TIMESTAMP_FORMAT in the SdkConstant
class is mutable and should be declared as final to make it truly constant.
Additionally, the SdkConstant class should be non-instantiable by adding a
private constructor. To fix this, add the final keyword to the
SDK_CHECK_ISO_TIMESTAMP_FORMAT field declaration (changing public static String
to public static final String), and add a private no-argument constructor to the
SdkConstant class to prevent instantiation of what should be a constants utility
class.
In `@matchsdk/src/main/java/io/mosip/mock/sdk/service/SDKInfoService.java`:
- Around line 35-39: The `supportedMethods` map is storing the same
`supportedModalities` list reference for all four BiometricFunction entries
(MATCH, QUALITY_CHECK, EXTRACT, CONVERT_FORMAT). If this list is mutated by any
consumer, all four methods will be affected. Fix this by creating a new copy of
the `supportedModalities` list for each put() call to `supportedMethods`, or
alternatively wrap each entry with Collections.unmodifiableList() to create
immutable copies. This ensures each BiometricFunction has its own independent
list instance.
In `@matchsdk/src/main/java/io/mosip/mock/sdk/util/Util.java`:
- Around line 24-30: The condition in the if-else block for handling null
metaData is creating a redundant array copy. When metaData is null, avoid the
unnecessary call to ArrayUtils.addAll(data) and instead pass the data array
directly to DigestUtils.sha256Hex(). Simplify the logic so that when metaData is
null, you call DigestUtils.sha256Hex(data) directly, and when metaData is not
null, keep the current logic that combines the arrays using
ArrayUtils.addAll(data, metaData.getBytes(StandardCharsets.UTF_8)).
- Around line 11-18: The compareHash method declares throws
NoSuchAlgorithmException but the underlying DigestUtils.sha256Hex handles
exception checking internally and never propagates this exception, making the
declaration misleading to callers. Remove the throws NoSuchAlgorithmException
clause from the compareHash method signature. Apply the same fix to the
computeFingerPrint method (which also declares the same throws clause) - remove
throws NoSuchAlgorithmException from its signature as well since it also uses
DigestUtils internally and never actually throws this exception.
In `@matchsdk/src/test/java/io/mosip/mock/sdk/MatchSDKTest.java`:
- Around line 743-744: The DocumentBuilderFactory instances in both test files
are created with default settings that leave XXE (XML External Entity)
processing enabled. Fix this by configuring the DocumentBuilderFactory to
disable external entity resolution and enable secure processing before calling
newDocumentBuilder(). Specifically, at
matchsdk/src/test/java/io/mosip/mock/sdk/MatchSDKTest.java lines 743-744, add
factory configuration calls between creating the DocumentBuilderFactory instance
and calling newDocumentBuilder() to disable DTD processing and external
entities. Apply the identical hardened factory configuration at
matchsdk/src/test/java/io/mosip/mock/sdk/SampleSDKTest.java lines 399-400 to
ensure consistent secure parsing behavior across both test files.
In `@matchsdk/src/test/java/io/mosip/mock/sdk/SDKServiceTest.java`:
- Around line 433-438: The test method
checkQuality_compoundFingerSubtype_coversSize2Branch currently only asserts that
the response is not null, which is insufficient for meaningful branch coverage
validation. Replace the non-deterministic assertion with explicit validation of
the expected response status. Based on the comment in the code indicating the
result should be either INVALID_INPUT (when ISO fails) or SUCCESS depending on
the data, assert that the response status matches one of these expected values.
This ensures the test will catch any unexpected status regressions in the
checkQuality method.
In `@matchsdk/src/test/java/io/mosip/mock/sdk/UtilTest.java`:
- Around line 33-46: The UtilTest class lacks edge-case tests for the
Util.compareHash method's null and empty input handling. Add three new test
methods to UtilTest: compareHash_nullFirstArray_returnsFalse to verify
compareHash returns false when the first parameter is null,
compareHash_nullSecondArray_returnsFalse to verify it returns false when the
second parameter is null, and compareHash_emptyFirstArray_returnsFalse to verify
it returns false when the first array is empty. Each test should follow the same
pattern as the existing compareHash test methods by creating appropriate test
data, calling Util.compareHash with the edge-case inputs, and asserting the
expected false result.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 8b78ad62-b37e-4c72-a681-a97d0db797a1
⛔ Files ignored due to path filters (1)
gradle/wrapper/gradle-wrapper.jaris excluded by!**/*.jar
📒 Files selected for processing (73)
.github/workflows/build.yml.gitignoreapp/.gitignoreapp/build.gradleapp/proguard-rules.proapp/src/androidTest/java/io/mosip/mock/sdk/ExampleInstrumentedTest.javaapp/src/main/AndroidManifest.xmlapp/src/main/res/drawable/ic_launcher_background.xmlapp/src/main/res/drawable/ic_launcher_foreground.xmlapp/src/main/res/mipmap-anydpi/ic_launcher.xmlapp/src/main/res/mipmap-anydpi/ic_launcher_round.xmlapp/src/main/res/mipmap-hdpi/ic_launcher.webpapp/src/main/res/mipmap-hdpi/ic_launcher_round.webpapp/src/main/res/mipmap-mdpi/ic_launcher.webpapp/src/main/res/mipmap-mdpi/ic_launcher_round.webpapp/src/main/res/mipmap-xhdpi/ic_launcher.webpapp/src/main/res/mipmap-xhdpi/ic_launcher_round.webpapp/src/main/res/mipmap-xxhdpi/ic_launcher.webpapp/src/main/res/mipmap-xxhdpi/ic_launcher_round.webpapp/src/main/res/mipmap-xxxhdpi/ic_launcher.webpapp/src/main/res/mipmap-xxxhdpi/ic_launcher_round.webpapp/src/main/res/values-night/themes.xmlapp/src/main/res/values/colors.xmlapp/src/main/res/values/strings.xmlapp/src/main/res/values/themes.xmlapp/src/main/res/xml/backup_rules.xmlapp/src/main/res/xml/data_extraction_rules.xmlapp/src/test/java/io/mosip/mock/sdk/ExampleUnitTest.javabuild.gradlegradle.propertiesgradle/wrapper/gradle-wrapper.propertiesgradlewgradlew.batmatchsdk/.gitignorematchsdk/build.gradlematchsdk/consumer-rules.promatchsdk/proguard-rules.promatchsdk/src/androidTest/java/io/mosip/mock/sdk/ExampleInstrumentedTest.javamatchsdk/src/main/AndroidManifest.xmlmatchsdk/src/main/java/io/mosip/mock/sdk/constant/ConverterErrorCode.javamatchsdk/src/main/java/io/mosip/mock/sdk/constant/ParameterCode.javamatchsdk/src/main/java/io/mosip/mock/sdk/constant/ResponseStatus.javamatchsdk/src/main/java/io/mosip/mock/sdk/constant/SdkConstant.javamatchsdk/src/main/java/io/mosip/mock/sdk/constant/SourceFormatCode.javamatchsdk/src/main/java/io/mosip/mock/sdk/constant/TargetFormatCode.javamatchsdk/src/main/java/io/mosip/mock/sdk/exception/ConversionException.javamatchsdk/src/main/java/io/mosip/mock/sdk/exception/SDKException.javamatchsdk/src/main/java/io/mosip/mock/sdk/impl/SampleSDK.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/CheckQualityService.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/ConvertFormatService.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/ExtractTemplateService.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/IConverterApi.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/MatchService.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/SDKInfoService.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/SDKService.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/SegmentService.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/impl/ConverterServiceImpl.javamatchsdk/src/main/java/io/mosip/mock/sdk/util/Util.javamatchsdk/src/test/java/io/mosip/mock/sdk/MatchSDKTest.javamatchsdk/src/test/java/io/mosip/mock/sdk/SDKServiceTest.javamatchsdk/src/test/java/io/mosip/mock/sdk/SampleSDKTest.javamatchsdk/src/test/java/io/mosip/mock/sdk/ServiceCoverageTest.javamatchsdk/src/test/java/io/mosip/mock/sdk/UtilTest.javamatchsdk/src/test/resources/sample_files/test_sdk.xmlmatchsdk/src/test/resources/sample_files/test_sdk_face_no_match.xmlmatchsdk/src/test/resources/sample_files/test_sdk_finger.xmlmatchsdk/src/test/resources/sample_files/test_sdk_finger_no_match.xmlmatchsdk/src/test/resources/sample_files/test_sdk_iris_no_match.xmlmatchsdk/src/test/resources/sample_files/test_sdk_match.xmlmatchsdk/src/test/resources/sample_files/test_sdk_more_fingers.xmlmatchsdk/src/test/resources/sample_files/test_sdk_no_matching_gallery.xmlmatchsdk/src/test/resources/sample_files/test_sdk_no_matching_sample.xmlsettings.gradle
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
There was a problem hiding this comment.
🧹 Nitpick comments (1)
matchsdk/src/main/java/io/mosip/mock/sdk/service/ConvertFormatService.java (1)
120-120: 💤 Low value
Integer.parseIntmay throwNumberFormatExceptionfor non-numeric error codes.If an
SDKExceptionis thrown with a non-numericerrorCode,Integer.parseInt(ex.getErrorCode())will throwNumberFormatException, which falls through to the genericExceptionhandler and returnsUNKNOWN_ERROR. This masks the actual exception type and makes debugging harder.Consider using a try-catch or
ResponseStatus.fromStatusCodethat handles parse failures gracefully:Suggested fix
} catch (SDKException ex) { LOGGER.error("convertFormat -- error", ex); - switch (ResponseStatus.fromStatusCode(Integer.parseInt(ex.getErrorCode()))) { + int statusCode; + try { + statusCode = Integer.parseInt(ex.getErrorCode()); + } catch (NumberFormatException nfe) { + response.setStatusCode(ResponseStatus.UNKNOWN_ERROR.getStatusCode()); + response.setStatusMessage(ResponseStatus.UNKNOWN_ERROR.getStatusMessage()); + response.setResponse(null); + return response; + } + switch (ResponseStatus.fromStatusCode(statusCode)) {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@matchsdk/src/main/java/io/mosip/mock/sdk/service/ConvertFormatService.java` at line 120, In the ConvertFormatService class where ResponseStatus.fromStatusCode is called with Integer.parseInt(ex.getErrorCode()), add a try-catch block around the parseInt call to handle NumberFormatException separately. When a NumberFormatException is caught (indicating the errorCode is non-numeric), either log it with appropriate details and return a default ResponseStatus, or pass a default value to fromStatusCode instead of attempting to parse the non-numeric error code. This ensures that actual parsing errors are properly handled and logged rather than being masked by the generic Exception handler.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@matchsdk/src/main/java/io/mosip/mock/sdk/service/ConvertFormatService.java`:
- Line 120: In the ConvertFormatService class where
ResponseStatus.fromStatusCode is called with
Integer.parseInt(ex.getErrorCode()), add a try-catch block around the parseInt
call to handle NumberFormatException separately. When a NumberFormatException is
caught (indicating the errorCode is non-numeric), either log it with appropriate
details and return a default ResponseStatus, or pass a default value to
fromStatusCode instead of attempting to parse the non-numeric error code. This
ensures that actual parsing errors are properly handled and logged rather than
being masked by the generic Exception handler.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: c6a05a94-8741-4276-b357-59b2a14d4f9a
📒 Files selected for processing (11)
.github/workflows/build.ymlmatchsdk/src/main/java/io/mosip/mock/sdk/exception/SDKException.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/ConvertFormatService.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/ExtractTemplateService.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/MatchService.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/SDKService.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/SegmentService.javamatchsdk/src/main/java/io/mosip/mock/sdk/service/impl/ConverterServiceImpl.javamatchsdk/src/test/java/io/mosip/mock/sdk/MatchSDKTest.javamatchsdk/src/test/java/io/mosip/mock/sdk/SampleSDKTest.javamatchsdk/src/test/java/io/mosip/mock/sdk/ServiceCoverageTest.java
💤 Files with no reviewable changes (1)
- .github/workflows/build.yml
🚧 Files skipped from review as they are similar to previous changes (7)
- matchsdk/src/main/java/io/mosip/mock/sdk/service/ExtractTemplateService.java
- matchsdk/src/test/java/io/mosip/mock/sdk/SampleSDKTest.java
- matchsdk/src/test/java/io/mosip/mock/sdk/MatchSDKTest.java
- matchsdk/src/main/java/io/mosip/mock/sdk/service/impl/ConverterServiceImpl.java
- matchsdk/src/test/java/io/mosip/mock/sdk/ServiceCoverageTest.java
- matchsdk/src/main/java/io/mosip/mock/sdk/service/MatchService.java
- matchsdk/src/main/java/io/mosip/mock/sdk/service/SDKService.java
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
|
@SachinPremkumar License text is missing in all the files |
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
Signed-off-by: Sachin S P <52343650+SachinPremkumar@users.noreply.github.com>
anushasunkada
approved these changes
Jun 17, 2026
ckm007
approved these changes
Jun 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
Release Notes
New Features
Tests
Chores