RCF-1354: Implemented the Maximum number of days without running the sync and added GPS location validation #664
Conversation
…sync job and geo-location validation Signed-off-by: sachin.sp <[email protected]>
WalkthroughAdds optional latitude/longitude to registration start APIs and flows, introduces a PreCheckValidatorService (interface + implementation) to validate sync-job frequencies and center-to-machine distance (throws ClientCheckedException), wires the service into DI and registration flow, updates UI to capture/pass GPS, and extends localization and tests. Changes
Sequence Diagram(s)sequenceDiagram
participant UI as Client/UI
participant DartSvc as Dart RegistrationService
participant Pigeon as RegistrationDataApi (Pigeon)
participant AndroidApi as RegistrationApi (Android)
participant RegSvc as RegistrationServiceImpl
participant PreVal as PreCheckValidatorService
participant SyncRepo as SyncJob/JobTransactionService
participant Master as MasterDataService
participant LocSvc as LocationValidationService
UI->>DartSvc: startRegistration(langs, flow, process, latitude?, longitude?)
DartSvc->>Pigeon: startRegistration(..., latitude?, longitude?)
Pigeon->>AndroidApi: startRegistration(..., latitude?, longitude?)
AndroidApi->>RegSvc: startRegistration(..., latitude, longitude)
activate RegSvc
RegSvc->>RegSvc: build RegistrationDto (set geo if present)
alt Latitude & Longitude provided
RegSvc->>PreVal: validateCenterToMachineDistance(longitude, latitude)
activate PreVal
PreVal->>Master: fetch registration center(s)
PreVal->>LocSvc: calculate distance(center, machine)
PreVal->>PreVal: compare with configured max distance
PreVal-->>RegSvc: pass / throw ClientCheckedException
deactivate PreVal
end
RegSvc->>PreVal: validateSyncStatus()
activate PreVal
PreVal->>SyncRepo: fetch active sync jobs & last transactions
PreVal->>PreVal: compute days since last sync vs configured frequency
PreVal-->>RegSvc: pass / throw ClientCheckedException
deactivate PreVal
RegSvc-->>AndroidApi: return RegistrationDto or error (mapped code)
deactivate RegSvc
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~30 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java:
- Around line 305-308: Replace the hardcoded English message in the
ClientCheckedException throw inside SyncStatusValidatorServiceImpl with a string
resource: add a new entry named err_outside_registration_center in strings.xml
containing the provided message, then call the existing throw new
ClientCheckedException(RegistrationConstants.OPT_TO_REG_OUTSIDE_LOCATION,
context.getString(R.string.err_outside_registration_center)) (or equivalent
using the available Context/Resources) so the exception uses
R.string.err_outside_registration_center instead of the literal string.
- Around line 223-231: getActualDays has an off-by-one: it adds +1 so a job
synced today yields 1, which with the existing comparison configuredFrequency <=
actualDays (used elsewhere) can mark non-overdue jobs as overdue; remove the +1
from getActualDays so it returns the true elapsed days ((int) daysDifference),
then run/adjust any tests or logic that rely on the old behavior (or
alternatively change the comparison to configuredFrequency < actualDays if you
prefer keeping the +1, but the simplest fix is to remove the +1 in
getActualDays).
In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/SyncStatusValidatorService.java:
- Around line 17-24: Update the Javadoc for
SyncStatusValidatorService.validateCenterToMachineDistance to document null
parameter behavior: state that machineLongitude and machineLatitude will skip
validation if null (e.g., "@param machineLongitude Machine longitude (validation
skipped if null)" and "@param machineLatitude Machine latitude (validation
skipped if null)"), ensuring the comment reflects the intended behavior of
skipping validation rather than throwing an exception.
🧹 Nitpick comments (7)
assets/l10n/app_en.arb (1)
305-305: Minor spelling inconsistency in error message.The new error tokens
OPT_TO_REG_TIME_SYNC_EXCEEDandOPT_TO_REG_OUTSIDE_LOCATIONare clear and actionable. However, there's a minor spelling inconsistency in the second message: it uses both "center" and "centre" (British spelling). Consider using consistent spelling throughout.✏️ Suggested consistency fix
-"errors": "{messages, select, REG_TRY_AGAIN{Login Failed. Try Again!} REG_INVALID_REQUEST{Password incorrect!} REG_MACHINE_NOT_FOUND{This device has not been onboarded yet. Please reach out to your administrator for assistance!} REG_NETWORK_ERROR{Login failed. Check network connection!} REG_CRED_EXPIRED{Credentials not found or are expired. Please try online login!} REG_MACHINE_INACTIVE{Machine is not active!} REG_CENTER_INACTIVE{Center is not active!} REG_LOGIN_LOCKED{Maximum login attempt limit reached. Try again later!} KER_SYN_AUTH_001{Unable to get Authentication Token!} PAK_APPRVL_MAX_TIME{Action required: Pending registered packets have exceeded the allowed approval time. Please clear the backlog to continue.} PAK_UPLOAD_MAX_TIME{Action required: Upload or export the packets to the server before proceeding with registration.} PAK_UPLOAD_MAX_COUNT{Action required: Packet limit reached. Please export or upload existing packets before creating new registrations.} OPT_TO_REG_TIME_SYNC_EXCEED{Time since last sync exceeded maximum limit. Please sync from server before proceeding with this registration.} OPT_TO_REG_OUTSIDE_LOCATION{Your client machine location is outside the registration center. Please note that registration can be done only from within the registration centre} other{'Some error occurred!'}}", +"errors": "{messages, select, REG_TRY_AGAIN{Login Failed. Try Again!} REG_INVALID_REQUEST{Password incorrect!} REG_MACHINE_NOT_FOUND{This device has not been onboarded yet. Please reach out to your administrator for assistance!} REG_NETWORK_ERROR{Login failed. Check network connection!} REG_CRED_EXPIRED{Credentials not found or are expired. Please try online login!} REG_MACHINE_INACTIVE{Machine is not active!} REG_CENTER_INACTIVE{Center is not active!} REG_LOGIN_LOCKED{Maximum login attempt limit reached. Try again later!} KER_SYN_AUTH_001{Unable to get Authentication Token!} PAK_APPRVL_MAX_TIME{Action required: Pending registered packets have exceeded the allowed approval time. Please clear the backlog to continue.} PAK_UPLOAD_MAX_TIME{Action required: Upload or export the packets to the server before proceeding with registration.} PAK_UPLOAD_MAX_COUNT{Action required: Packet limit reached. Please export or upload existing packets before creating new registrations.} OPT_TO_REG_TIME_SYNC_EXCEED{Time since last sync exceeded maximum limit. Please sync from server before proceeding with this registration.} OPT_TO_REG_OUTSIDE_LOCATION{Your client machine location is outside the registration center. Please note that registration can be done only from within the registration center} other{'Some error occurred!'}}",android/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/SyncStatusValidatorService.java (1)
8-15: Consider narrowing exception types for better error handling.Both methods declare
throws Exception, which is overly broad and makes it difficult for callers to handle specific validation failures distinctly. Consider introducing specific exception types (e.g.,SyncStatusException,LocationValidationException) or using existing domain-specific exceptions from the codebase.💡 Refactoring suggestion
public interface SyncStatusValidatorService { /** * Validates sync job frequencies. * - * @throws Exception if validation fails + * @throws ClientCheckedException if validation fails */ - void validateSyncStatus() throws Exception; + void validateSyncStatus() throws ClientCheckedException;android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)
3-7: Duplicate import detected.
java.util.ArrayListis imported twice on lines 4 and 5. Also,java.sql.Arrayon line 3 appears unused in this file.🧹 Proposed fix
package io.mosip.registration.clientmanager.constant; -import java.sql.Array; -import java.util.ArrayList; -import java.util.ArrayList; import java.util.Arrays; import java.util.List;android/clientmanager/src/test/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImplTest.java (3)
86-93: Redundant mock initialization.When using
@RunWith(MockitoJUnitRunner.class), mocks annotated with@Mockand@InjectMocksare automatically initialized. The explicitMockitoAnnotations.openMocks(this)call on line 88 is redundant and can be removed.🧹 Proposed fix
@Before public void setUp() { - MockitoAnnotations.openMocks(this); when(mockContext.getString(R.string.app_name)).thenReturn("RegistrationClient"); when(mockContext.getSharedPreferences(anyString(), anyInt())).thenReturn(mockSharedPreferences); when(mockSharedPreferences.edit()).thenReturn(mockEditor); when(mockEditor.putLong(anyString(), anyLong())).thenReturn(mockEditor); }
404-430: Inconsistent test pattern.This test uses
try-catch-fail()pattern while other similar tests use@Test(expected = ClientCheckedException.class). For consistency, consider using the same pattern across all exception tests.🧹 Proposed fix
- @Test - public void testValidateCenterToMachineDistance_InvalidCoordinateFormat_ThrowsException() throws Exception { + @Test(expected = ClientCheckedException.class) + public void testValidateCenterToMachineDistance_InvalidCoordinateFormat_ThrowsException() throws Exception { // Setup: GPS enabled when(mockGlobalParamRepository.getCachedStringGpsDeviceEnableFlag()).thenReturn("N"); // Setup: Center details CenterMachineDto centerMachineDto = new CenterMachineDto(); centerMachineDto.setCenterId(CENTER_ID); when(mockMasterDataService.getRegistrationCenterMachineDetails()).thenReturn(centerMachineDto); RegistrationCenter center = new RegistrationCenter(); center.setId(CENTER_ID); center.setLangCode("eng"); center.setLatitude("invalid"); // Invalid format center.setLongitude("77.5946"); List<RegistrationCenter> centers = new ArrayList<>(); centers.add(center); when(mockRegistrationCenterRepository.getRegistrationCenter(CENTER_ID)).thenReturn(centers); // Execute - should throw exception - try { - syncStatusValidatorService.validateCenterToMachineDistance(78.5946, 13.9716); - fail("Expected ClientCheckedException for invalid coordinate format"); - } catch (ClientCheckedException e) { - // Expected - } + syncStatusValidatorService.validateCenterToMachineDistance(78.5946, 13.9716); }
244-255: Test name and comment are misleading about the GPS_DEVICE_ENABLE_FLAG semantics.The test correctly validates that validation is skipped when the flag is
"Y", but the test nameGPSDisabled_Skippedand comment "GPS validation disabled" create confusion. WhenGPS_DEVICE_ENABLE_FLAGis"Y", it means the GPS device is enabled/present, not that GPS is disabled. The implementation intentionally skips distance validation when a GPS device is available, allowing users to manually verify location.Rename or clarify the test to reflect the actual flag semantics:
- Test should indicate that GPS device is enabled when the flag is
"Y"- Comment should explain that validation is skipped because GPS device is available for manual verification
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (1)
159-163: Consider logging at appropriate level for swallowed exceptions.The exception handling here silently continues to the next job, which is appropriate for resilience. However, for
NumberFormatException(line 160),Log.e(error level) may be too severe for what is essentially a configuration issue. Consider usingLog.w(warning) instead.🧹 Proposed fix
} catch (NumberFormatException e) { - Log.e(TAG, "Invalid frequency value for job: " + jobId + " (" + apiName + "): " + configuredFrequencyStr, e); + Log.w(TAG, "Invalid frequency value for job: " + jobId + " (" + apiName + "): " + configuredFrequencyStr + " - skipping validation"); } catch (Exception e) { Log.e(TAG, "Error validating job: " + jobId + " (" + apiName + ")", e); }
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
android/app/src/main/java/io/mosip/registration_client/api_services/RegistrationApi.javaandroid/clientmanager/src/main/java/io/mosip/registration/clientmanager/config/AppModule.javaandroid/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.javaandroid/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.javaandroid/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.javaandroid/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/SyncStatusValidatorService.javaandroid/clientmanager/src/test/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImplTest.javaassets/l10n/app_ar.arbassets/l10n/app_en.arbassets/l10n/app_fr.arbassets/l10n/app_hi.arbassets/l10n/app_kn.arbassets/l10n/app_ta.arb
🧰 Additional context used
🧬 Code graph analysis (3)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (3)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/GlobalParamRepository.java (1)
GlobalParamRepository(21-254)android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/RegistrationCenterRepository.java (1)
RegistrationCenterRepository(11-39)android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/SyncJobDefRepository.java (1)
SyncJobDefRepository(18-39)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/config/AppModule.java (2)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java (1)
Singleton(96-771)android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (1)
Singleton(35-318)
android/clientmanager/src/test/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImplTest.java (4)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)
RegistrationConstants(9-148)android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/GlobalParamRepository.java (1)
GlobalParamRepository(21-254)android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/RegistrationCenterRepository.java (1)
RegistrationCenterRepository(11-39)android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/SyncJobDefRepository.java (1)
SyncJobDefRepository(18-39)
🔇 Additional comments (19)
android/app/src/main/java/io/mosip/registration_client/api_services/RegistrationApi.java (1)
27-27: LGTM! Clean error handling for validation exceptions.The addition of
ClientCheckedExceptionhandling enables structured validation error propagation. The catch block is correctly positioned before the genericExceptionhandler, and returninge.getErrorCode()allows the Flutter layer to receive specific error codes (likeOPT_TO_REG_TIME_SYNC_EXCEEDandOPT_TO_REG_OUTSIDE_LOCATION) for localized display.Also applies to: 56-57
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/config/AppModule.java (3)
51-51: LGTM! Proper service imports added.The imports for
SyncStatusValidatorServiceImpl(concrete implementation) andSyncStatusValidatorService(interface) are correctly added to support the new validation service.Also applies to: 65-65
211-212: LGTM! Dependency injection correctly updated.The
provideRegistrationServicemethod signature now includesSyncStatusValidatorServiceas a parameter, and the service is properly passed to theRegistrationServiceImplconstructor. This follows the existing DI patterns in the module.Also applies to: 215-215
316-328: LGTM! Well-structured provider method.The
provideSyncStatusValidatorServiceprovider method correctly:
- Returns the interface type (
SyncStatusValidatorService) rather than the implementation- Provides all 8 required dependencies for
SyncStatusValidatorServiceImpl- Is annotated as
@Singletonfor proper lifecycle management- Follows Dagger conventions used throughout this module
assets/l10n/app_kn.arb (1)
305-305: LGTM! Localization tokens added for Kannada.The two new error tokens (
OPT_TO_REG_TIME_SYNC_EXCEEDandOPT_TO_REG_OUTSIDE_LOCATION) have been added to the Kannada localization file, maintaining consistency with the English version.assets/l10n/app_hi.arb (1)
305-305: LGTM! Localization tokens added for Hindi.The two new error tokens (
OPT_TO_REG_TIME_SYNC_EXCEEDandOPT_TO_REG_OUTSIDE_LOCATION) have been added to the Hindi localization file, maintaining consistency with the English version.assets/l10n/app_ar.arb (1)
305-305: LGTM: Localization keys added for new validation features.The Arabic translations for the two new error messages (
OPT_TO_REG_TIME_SYNC_EXCEEDandOPT_TO_REG_OUTSIDE_LOCATION) have been added consistently with the existing error message pattern.assets/l10n/app_fr.arb (1)
305-305: LGTM: Localization keys added for new validation features.The French translations for the two new error messages (
OPT_TO_REG_TIME_SYNC_EXCEEDandOPT_TO_REG_OUTSIDE_LOCATION) have been added consistently with the existing error message pattern.assets/l10n/app_ta.arb (1)
314-314: LGTM: Localization keys added for new validation features.The Tamil translations for the two new error messages (
OPT_TO_REG_TIME_SYNC_EXCEEDandOPT_TO_REG_OUTSIDE_LOCATION) have been added consistently with the existing error message pattern.android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java (3)
71-71: LGTM: Dependency injection properly implemented.The
SyncStatusValidatorServicedependency has been correctly wired through constructor injection, following the existing pattern used for other services in this class. The field is properly declared, assigned, and ready for use.Also applies to: 118-118, 136-137, 153-153
575-578: LGTM: Sync status validation properly placed in pre-checks.The sync status validation is correctly positioned in the pre-registration checks sequence, ensuring validation occurs before any registration processing begins. The null-safe invocation pattern is consistent with other optional validations in this method.
200-210: Parameter order is correct and consistent with the method signature.The call at lines 203-205 passes
longitudethenlatitude, which matches thevalidateCenterToMachineDistance(Double machineLongitude, Double machineLatitude)method signature. Lines 500-503 only access the fields separately, not as method parameters, so they don't establish a different ordering convention. The code is internally consistent; parameter order is not an issue.Regarding timing: Validation immediately follows DTO initialization, which is appropriate since the geolocation data must be available to validate it. The DTO is a lightweight data container (initialized with the constructor parameters), not a resource-heavy object, so early vs. late validation has minimal practical impact.
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)
121-148: LGTM!The new constants are appropriately named and follow existing conventions. They correctly support the new sync status and GPS location validation features.
android/clientmanager/src/test/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImplTest.java (2)
269-300: LGTM!The test correctly validates the success scenario when the machine is within the allowed distance from the registration center. Mock setup is clean and assertions verify the expected behavior.
521-539: LGTM!The helper method is well-structured and promotes test code reuse across multiple test cases.
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (4)
49-67: LGTM!Constructor properly injects all required dependencies for the validation service.
244-248: GPS flag logic may be inverted.The condition skips validation when
enableFlagis"Y"(GPS device enabled). This is counterintuitive—typically you would validate distance when GPS is available, not skip it.If
GPS_DEVICE_ENABLE_FLAG = "Y"means "GPS validation should be enabled," then the condition should be inverted:🔧 Potential fix if logic is inverted
String enableFlag = globalParamRepository.getCachedStringGpsDeviceEnableFlag(); - if (enableFlag == null || "Y".equalsIgnoreCase(enableFlag)) { - Log.d(TAG, "GPS distance validation disabled or not configured, skipping"); + if (enableFlag == null || "N".equalsIgnoreCase(enableFlag)) { + Log.d(TAG, "GPS device disabled or not configured, skipping distance validation"); return; }Please verify the intended semantics of
GPS_DEVICE_ENABLE_FLAG:
- Does
"Y"mean GPS device is enabled (and validation should run)?- Or does
"Y"mean GPS validation feature should be bypassed?
35-47: LGTM!The service is correctly annotated as
@Singletonand doesn't maintain shared mutable state. Thread safety depends on injected dependencies, which should be thread-safe by design.
165-170: LGTM!The error message construction clearly communicates the validation failure with actionable details about which jobs are overdue.
.../src/main/java/io/mosip/registration/clientmanager/service/PreCheckValidatorServiceImpl.java
Show resolved
Hide resolved
.../src/main/java/io/mosip/registration/clientmanager/service/PreCheckValidatorServiceImpl.java
Show resolved
Hide resolved
...tmanager/src/main/java/io/mosip/registration/clientmanager/spi/PreCheckValidatorService.java
Show resolved
Hide resolved
Signed-off-by: sachin.sp <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java:
- Around line 244-248: The GPS enable-flag check is inverted: currently it
returns (skips validation) when enableFlag is "Y"; change the condition so the
method only skips when the flag is absent or not set to "Y". Locate the
getCachedStringGpsDeviceEnableFlag() call and the surrounding if using the
enableFlag variable in SyncStatusValidatorServiceImpl, and replace the predicate
with one that returns early when enableFlag == null ||
!"Y".equalsIgnoreCase(enableFlag) so that validation runs only when the flag is
"Y".
In @android/clientmanager/src/main/res/values/strings.xml:
- Line 15: The message string named err_outside_registration_center uses both
"center" and "centre"; pick one spelling and make them consistent in the string
value (e.g., change both to "center" or both to "centre") so the displayed
message uses the same variant throughout while keeping the existing identifier
err_outside_registration_center unchanged.
🧹 Nitpick comments (3)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/SyncStatusValidatorService.java (1)
10-24: Consider declaringClientCheckedExceptioninstead of genericException.Both methods throw
Exception, but the implementation only throwsClientCheckedException. Declaring the more specific exception type improves API clarity and enables callers to handle validation failures distinctly.♻️ Suggested refinement
- void validateSyncStatus() throws Exception; + void validateSyncStatus() throws ClientCheckedException; ... - void validateCenterToMachineDistance(Double machineLongitude, Double machineLatitude) throws Exception; + void validateCenterToMachineDistance(Double machineLongitude, Double machineLatitude) throws ClientCheckedException;android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (2)
3-5: Remove unused import.
SharedPreferencesis imported but never used in this class.🧹 Suggested fix
import android.content.Context; -import android.content.SharedPreferences; import android.util.Log;
273-277: Inconsistent handling of missing data.When center details or center list is unavailable (lines 256-267), validation is skipped. However, when center coordinates are missing, an exception is thrown. Consider consistent behavior—either skip validation (if this is expected in some setups) or fail consistently for all missing center data.
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.javaandroid/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/SyncStatusValidatorService.javaandroid/clientmanager/src/main/res/values/strings.xml
🧰 Additional context used
🧬 Code graph analysis (1)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (4)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)
RegistrationConstants(9-148)android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/GlobalParamRepository.java (1)
GlobalParamRepository(21-254)android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/RegistrationCenterRepository.java (1)
RegistrationCenterRepository(11-39)android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/SyncJobDefRepository.java (1)
SyncJobDefRepository(18-39)
🔇 Additional comments (3)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (3)
74-91: LGTM!The exception handling properly distinguishes between expected validation failures and unexpected errors, with appropriate logging.
148-157: Verify the boundary condition for overdue detection.Using
<=means a job withconfiguredFrequency=7is marked overdue whenactualDays=7(exactly at the limit). If the intent is "must sync within N days," the job should be overdue only after exceeding the limit (i.e.,actualDays > configuredFrequency).Please confirm whether a sync performed exactly at the configured frequency limit should block registration. If "within N days" is the requirement, consider:
- if (configuredFrequency <= actualDays) { + if (actualDays > configuredFrequency) {
223-231: LGTM!The day calculation logic correctly uses day-level granularity with appropriate null handling.
.../src/main/java/io/mosip/registration/clientmanager/service/PreCheckValidatorServiceImpl.java
Show resolved
Hide resolved
Signed-off-by: sachin.sp <[email protected]>
…registration-client into RCF-1354 # Conflicts: # android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java:
- Around line 148-157: The condition treating syncs as overdue uses <= which
flags jobs that ran exactly at the configured interval; change the comparison in
the sync validation block that references configuredFrequency and actualDays to
use a strict greater-than (actualDays > configuredFrequency) so only jobs that
exceeded the configuredFrequency increment syncFailureCount, append to
errorDetails, and log the overdue message for jobId/apiName; update the
conditional around the existing syncFailureCount++, errorDetails.append(...),
and Log.w(...) accordingly.
🧹 Nitpick comments (1)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (1)
75-75: Consider more specific exception declaration.The method signature declares
throws Exception, which is very broad. Consider declaringthrows ClientCheckedExceptionor a more specific exception type to improve type safety and make the contract clearer to callers.♻️ Suggested improvement
- public void validateSyncStatus() throws Exception { + public void validateSyncStatus() throws ClientCheckedException {
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.javaandroid/clientmanager/src/main/res/values/strings.xml
🚧 Files skipped from review as they are similar to previous changes (1)
- android/clientmanager/src/main/res/values/strings.xml
🔇 Additional comments (5)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (5)
35-47: LGTM: Clean dependency injection setup.The singleton service is properly structured with all dependencies declared as private fields and injected via constructor using Dagger.
49-67: LGTM: Constructor follows Dagger injection pattern.All dependencies are properly assigned. Dagger's DI contract ensures non-null values at runtime.
181-215: LGTM: Proper configuration retrieval with null safety.The method correctly builds property names from constants, retrieves configuration values, and filters out invalid entries (null, empty, or literal "null" strings). Good defensive programming.
223-231: LGTM: Day calculation is mathematically correct.The integer division at line 229 truncates partial days (e.g., 5 days 23 hours becomes 5 days), which is the expected behavior for calculating whole days since last sync.
241-316: LGTM: Robust GPS distance validation with proper error handling.The method correctly:
- Checks GPS enable flag and coordinates availability with early returns
- Retrieves center details with null safety
- Calculates and converts distance (km to meters)
- Uses strict
>comparison at line 301 (machines at exactly the max distance are allowed)- Handles parsing exceptions and missing configurations appropriately
...rc/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)
3-7: Remove duplicate import statement.Line 5 contains a duplicate import of
java.util.ArrayList(also imported on Line 4).🧹 Proposed fix
import java.sql.Array; import java.util.ArrayList; -import java.util.ArrayList; import java.util.Arrays; import java.util.List;
🤖 Fix all issues with AI agents
In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java:
- Around line 200-210: The GPS distance validation is never reached because
registrationDto.getGeoLocationDto() is not populated before validation; move the
validateCenterToMachineDistance(...) call out of the constructor/init path and
execute it after the location is set (i.e., after setMachineLocation() in
RegistrationApi.java) or call registrationDto.setGeoLocation(...) prior to this
validation; specifically, ensure
syncStatusValidatorService.validateCenterToMachineDistance(...) is invoked in
the same flow/method that sets the geo location (or add a post-location-capture
hook) so validateCenterToMachineDistance(...) runs with a non-null
registrationDto.getGeoLocationDto().
🧹 Nitpick comments (1)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)
148-152: Consider more specific names for generic string builder constants.The constants
DOTandFREQUENCYare very generic and could potentially be reused in unrelated contexts, making the code harder to maintain. If these are specifically for building sync validation configuration keys, consider more descriptive names likeSYNC_KEY_DOTandSYNC_KEY_FREQUENCY, or consolidate key construction into a helper method.Alternative approach
If these constants are only used to build configuration keys like
"mosip.registration.{jobId}.frequency", consider a helper method instead:// Instead of public generic constants, use a helper method public static String buildSyncFrequencyKey(String jobId) { return "mosip.registration." + jobId + ".frequency"; }This eliminates the need for public
DOTandFREQUENCYconstants while making the intent clearer.
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.javaandroid/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java
🔇 Additional comments (3)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java (2)
71-71: LGTM: Service wiring is correct.The SyncStatusValidatorService is properly imported, declared as a field, added to the constructor, and assigned. The dependency injection follows the established pattern in this class.
Also applies to: 118-118, 136-137, 153-153
576-579: LGTM: Sync status validation is properly integrated.The validation is correctly placed in the pre-check sequence before registration begins. The null check is defensive and consistent with other service checks in this method (Lines 582, 587, 592). The comment clearly explains the purpose of the validation.
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)
121-123: LGTM: GPS and registration option constants are well-defined.The new constants
GEO_CAP_FREQ,OPT_TO_REG_OUTSIDE_LOCATION, andOPT_TO_REG_LAST_CAPTURED_TIMEfollow the existing naming conventions and are appropriately placed near related GPS configuration constants.
...nager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java
Outdated
Show resolved
Hide resolved
Signed-off-by: sachin.sp <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java:
- Around line 200-210: The distance validation block is dead because
registrationDto.getGeoLocationDto() is null at startRegistration(); move the
check out of startRegistration() and into a point after setMachineLocation() is
called (or into packet submission) so GPS is guaranteed to be present.
Specifically, remove or disable the validateCenterToMachineDistance call in
RegistrationServiceImpl.startRegistration(), and invoke
syncStatusValidatorService.validateCenterToMachineDistance(...) after
setMachineLocation(...) completes (or inside the packet creation/submission
flow), keeping the same exception handling (catch ClientCheckedException,
Log.e(TAG,...), rethrow) and using
registrationDto.getGeoLocationDto().getLongitude()/getLatitude() as before.
In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java:
- Around line 241-316: In validateCenterToMachineDistance, when
getCachedStringGpsDeviceEnableFlag() is "Y" do not silently skip if
machineLongitude or machineLatitude are null: replace the early return for null
machine coords with a thrown ClientCheckedException (use the same client error
pattern/context as other failures, e.g., new ClientCheckedException(context,
R.string.err_004)) so GPS-enabled mode enforces presence of device location;
also update the NumberFormatException log message in the catch block from
"Invalid center coordinates format" to "Invalid number format in center
coordinates or max distance configuration" and include the exception object in
the log to reflect that Double.parseDouble(maxDistanceStr) can fail.
🧹 Nitpick comments (4)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java (2)
118-154: MakeSyncStatusValidatorServicea required injected dependency (avoid silent validation bypass).Right now
syncStatusValidatorServiceis constructor-injected but all call sites guard it with!= null, which can hide DI misconfiguration and silently skip “must-run” validations (sync-status and distance). Prefer enforcing non-null via constructor and dropping the null checks (or failing fast).Proposed adjustment
@@ - private SyncStatusValidatorService syncStatusValidatorService; + private final SyncStatusValidatorService syncStatusValidatorService; @@ public RegistrationServiceImpl(Context context, PacketWriterService packetWriterService, @@ - PacketService packetService, - SyncStatusValidatorService syncStatusValidatorService) { + PacketService packetService, + SyncStatusValidatorService syncStatusValidatorService) { @@ this.packetService = packetService; - this.syncStatusValidatorService = syncStatusValidatorService; + if (syncStatusValidatorService == null) { + throw new IllegalArgumentException("syncStatusValidatorService must not be null"); + } + this.syncStatusValidatorService = syncStatusValidatorService; }
200-210: Redundant catch/rethrow (log once at the boundary).Catching
ClientCheckedException, logging, and rethrowing doesn’t change behavior. If you want centralized logging, prefer logging at the API boundary (where errors are presented to callers) to avoid double logs; otherwise remove the try/catch.android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (2)
40-67: Preferfinalfields for injected dependencies.These are constructor-injected and never reassigned; marking them
finalreduces accidental mutation and improves thread-safety/readability.Proposed adjustment
@@ - private Context context; - private SyncJobDefRepository syncJobDefRepository; - private GlobalParamRepository globalParamRepository; - private JobManagerService jobManagerService; - private JobTransactionService jobTransactionService; - private LocationValidationService locationValidationService; - private MasterDataService masterDataService; - private RegistrationCenterRepository registrationCenterRepository; + private final Context context; + private final SyncJobDefRepository syncJobDefRepository; + private final GlobalParamRepository globalParamRepository; + private final JobManagerService jobManagerService; + private final JobTransactionService jobTransactionService; + private final LocationValidationService locationValidationService; + private final MasterDataService masterDataService; + private final RegistrationCenterRepository registrationCenterRepository;
223-231: Day calculation: considerjava.time/TimeUnitto avoid edge cases.The integer division is OK, but using
TimeUnit.MILLISECONDS.toDays(...)orjava.time.Instant+ChronoUnit.DAYSis clearer and avoids “magic numbers”.
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.javaandroid/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java
🔇 Additional comments (2)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java (1)
576-579: Sync-status pre-check placement looks good; ensure it’s “fail-closed” if required.Calling
validateSyncStatus()insidedoPreChecksBeforeRegistration(...)is the right place to block early. As above, consider removing thesyncStatusValidatorService != nullguard if this validation is mandatory.android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (1)
181-215: No issue: MOSIP_REGISTRATION constant already includes the required dot separator.The constant
MOSIP_REGISTRATION = "mosip.registration."already includes the trailing dot, so the propertyName is correctly formatted asmosip.registration.{apiName}.frequency. The key format is valid and will not cause silent lookup failures due to missing separators.Likely an incorrect or invalid review comment.
...nager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java
Outdated
Show resolved
Hide resolved
.../src/main/java/io/mosip/registration/clientmanager/service/PreCheckValidatorServiceImpl.java
Show resolved
Hide resolved
.../src/main/java/io/mosip/registration/clientmanager/service/PreCheckValidatorServiceImpl.java
Show resolved
Hide resolved
.../src/main/java/io/mosip/registration/clientmanager/service/PreCheckValidatorServiceImpl.java
Show resolved
Hide resolved
Signed-off-by: sachin.sp <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@lib/ui/process_ui/widgets/language_selector.dart`:
- Around line 85-106: The fetchLocation call can hang because
Geolocator.getCurrentPosition lacks a timeLimit; update the fetchLocation
implementation to pass a timeLimit (e.g., Duration(seconds:10)) to
Geolocator.getCurrentPosition and ensure it returns null or throws a controlled
exception on timeout, and additionally defend the UI call in
language_selector.dart by wrapping globalProvider.fetchLocation() with a timeout
(e.g., .timeout(Duration(seconds:10), onTimeout: () => null)) so the await in
the widget (where globalProvider.fetchLocation() is called before
startRegistration) will not block indefinitely; keep existing try/catch/null
checks around the position and preserve passing latitude/longitude into
registrationTaskProvider.startRegistration.
In `@pigeon/registration_data.dart`:
- Around line 14-17: The RegistrationDataApi signature (startRegistration with
nullable double? latitude and longitude) is correct but the generated Pigeon
bindings are missing; run the pigeon generator script (./pigeon.sh) to produce
the Dart and platform artifacts referenced by registration_service_impl.dart:
lib/pigeon/registration_data_pigeon.dart,
android/app/src/main/java/io/mosip/registration_client/model/RegistrationDataPigeon.java,
and ios/Runner/pigeon.h and ios/Runner/pigeon.m; ensure the generated files are
created locally (they remain gitignored) so the
RegistrationDataApi/startRegistration changes compile and the Pigeon API calls
in RegistrationServiceImpl work.
♻️ Duplicate comments (2)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (2)
115-127: Policy consideration: missing config or sync history allows registration to proceed.The current implementation skips validation (allows registration) when:
- Configured frequency is missing/blank (lines 116-118)
- No sync history exists (lines 125-127)
If the intent is strict enforcement of sync requirements, these cases should fail-closed instead of skip. If this is intentional for backwards compatibility or gradual rollout, consider documenting this behavior.
216-218: Verify intended behavior: missing machine coordinates bypass validation when GPS is enabled.When
enableFlagis"Y"(GPS validation enabled), nullmachineLongitudeormachineLatitudecauses the method to return without validating. If GPS validation should be enforced when enabled, this should throw an error rather than silently skip.If this is intentional fallback behavior (e.g., for devices without GPS hardware), consider documenting this decision.
🧹 Nitpick comments (2)
android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (2)
74-85: Acceptable error handling, but consider a dedicated error code for sync validation failures.The catch-all mapping to
err_004is defensive but may obscure the actual failure mode. If distinct error messaging is needed for debugging or UX, consider adding a specific error code for "sync validation failed unexpectedly."
272-274: Improve exception message accuracy.The
NumberFormatExceptioncan be thrown by either center coordinate parsing (lines 245-246) or max distance parsing (line 260). The current log message "Invalid center coordinates format" doesn't cover the latter case.📝 Suggested improvement
} catch (NumberFormatException e) { - Log.e(TAG, "Invalid center coordinates format", e); + Log.e(TAG, "Invalid number format in center coordinates or max distance configuration", e); throw new ClientCheckedException(context, R.string.err_004); }
Signed-off-by: sachin.sp <[email protected]>
There was a problem hiding this comment.
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 (1)
lib/provider/global_provider.dart (1)
887-923: HandleTimeoutExceptionfromgetCurrentPositionto preserve null-on-failure contract.
Geolocator.getCurrentPosition()withtimeLimitthrowsTimeoutExceptionwhen position acquisition exceeds the specified duration. The current code lacks exception handling, which will cause unhandled exceptions to escape despite the method contract stating it returnsnullon failure. Wrap the call in a try-catch block and returnnullon timeout to maintain consistency:Suggested fix
// Fetch location if permission is granted // Add timeout to prevent indefinite hanging - return await Geolocator.getCurrentPosition( - desiredAccuracy: LocationAccuracy.high, - timeLimit: const Duration(seconds: 10), - ); + try { + return await Geolocator.getCurrentPosition( + desiredAccuracy: LocationAccuracy.high, + timeLimit: const Duration(seconds: 10), + ); + } on TimeoutException { + return null; + }
🧹 Nitpick comments (4)
lib/ui/process_ui/widgets/language_selector.dart (1)
99-119: Add amountedguard before usingcontextafter awaits.This async flow now includes more awaited work; guard against
setState/navigation on a disposed widget.♻️ Proposed fix
await registrationTaskProvider.startRegistration( langList, widget.newProcess.flow! == "UPDATE" ? "Update" : widget.newProcess.flow!, widget.newProcess.id!, latitude: latitude, longitude: longitude); + if (!mounted) return; + registrationTaskProvider.addDemographicField("preferredLang", globalProvider.fieldInputValue["preferredLang"].toString()); String registrationStartError = registrationTaskProvider.registrationStartError;android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (3)
4-4: Remove unused import.
SharedPreferencesis imported but not used anywhere in this class.-import android.content.SharedPreferences;
40-47: Consider making fieldsfinalfor immutability.Since these dependencies are set once in the constructor and never reassigned, marking them
finaldocuments the intent and prevents accidental modification.- private Context context; - private SyncJobDefRepository syncJobDefRepository; - private GlobalParamRepository globalParamRepository; - private JobManagerService jobManagerService; - private JobTransactionService jobTransactionService; - private LocationValidationService locationValidationService; - private MasterDataService masterDataService; - private RegistrationCenterRepository registrationCenterRepository; + private final Context context; + private final SyncJobDefRepository syncJobDefRepository; + private final GlobalParamRepository globalParamRepository; + private final JobManagerService jobManagerService; + private final JobTransactionService jobTransactionService; + private final LocationValidationService locationValidationService; + private final MasterDataService masterDataService; + private final RegistrationCenterRepository registrationCenterRepository;
250-281: Consider broader exception handling forgetDistance()call.The try-catch block only handles
NumberFormatException. IflocationValidationService.getDistance()throws a different exception (e.g.,IllegalArgumentExceptionfor invalid coordinates), it will propagate with a raw error message rather than a user-friendly message.Suggested improvement
} catch (NumberFormatException e) { Log.e(TAG, "Invalid number format in center coordinates or max distance configuration", e); throw new ClientCheckedException(context, R.string.err_004); + } catch (Exception e) { + Log.e(TAG, "Error during distance validation", e); + throw new ClientCheckedException(context, R.string.err_004); }
Signed-off-by: sachin.sp <[email protected]>
...nager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java
Outdated
Show resolved
Hide resolved
…registration-client into RCF-1354 # Conflicts: # android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java # assets/l10n/app_ar.arb # assets/l10n/app_en.arb # assets/l10n/app_fr.arb # assets/l10n/app_hi.arb # assets/l10n/app_kn.arb # assets/l10n/app_ta.arb
Signed-off-by: sachin.sp <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In
`@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/PreCheckValidatorService.java`:
- Around line 18-22: The Javadoc contract for PreCheckValidatorService is
inconsistent with the implementation: update the documentation for the method
that validates machine distance (the one with parameters machineLongitude and
machineLatitude) to state that validation is only skipped when GPS is disabled
and that when GPS is enabled the coordinates are required (non-null) and an
Exception will be thrown if they are missing or the machine is outside the
allowed distance; ensure the method signature and throws clause remain unchanged
and mirror the implementation semantics so tests/docs and
PreCheckValidatorService implementation are aligned.
In
`@android/clientmanager/src/test/java/io/mosip/registration/clientmanager/service/RegistrationServiceImplTest.java`:
- Around line 1873-2043: The test uses verify(preCheckValidatorService,
never()).validateCenterToMachineDistance(anyDouble(), anyDouble()) which can
miss calls with null args; update the assertions to ensure no invocation
actually happened by either using verifyNoInteractions(preCheckValidatorService)
or changing the matcher to null-tolerant matchers (e.g.,
verify(preCheckValidatorService, never()).validateCenterToMachineDistance(any(),
any()) or use isNull() for the specific null-arg cases) for the tests around
validateCenterToMachineDistance so the verification fails if the method was
called with nulls.
In `@lib/provider/global_provider.dart`:
- Around line 944-948: The call to Geolocator.getCurrentPosition with a
timeLimit can throw a TimeoutException which is currently uncaught; inside the
surrounding method (the method that calls Geolocator.getCurrentPosition in
global_provider.dart) wrap the await Geolocator.getCurrentPosition(...) call in
a try/catch that catches TimeoutException (from dart:async) and returns null on
timeout, while preserving existing exception handling for other error paths;
ensure dart:async is imported if not already and only convert the timeout case
to a null return so the method's contract stays consistent.
...tmanager/src/main/java/io/mosip/registration/clientmanager/spi/PreCheckValidatorService.java
Outdated
Show resolved
Hide resolved
...r/src/test/java/io/mosip/registration/clientmanager/service/RegistrationServiceImplTest.java
Show resolved
Hide resolved
Signed-off-by: sachin.sp <[email protected]>
Signed-off-by: sachin.sp <[email protected]>
…registration-client into RCF-1354 # Conflicts: # android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java # assets/l10n/app_ar.arb # assets/l10n/app_en.arb # assets/l10n/app_fr.arb # assets/l10n/app_hi.arb # assets/l10n/app_kn.arb # assets/l10n/app_ta.arb
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@assets/l10n/app_kn.arb`:
- Line 305: Fix the formatting in the "errors" select string by inserting a
missing space between the closing brace of PAK_DISK_SPACE_LOW{...} and the next
selector REG_PKT_APPRVL_CNT_EXCEED; locate the "errors" entry in
assets/l10n/app_kn.arb and add a single space before "REG_PKT_APPRVL_CNT_EXCEED"
so the selectors are consistently separated (match the spacing used in the
English locale).
Signed-off-by: sachin.sp <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@assets/l10n/app_kn.arb`:
- Line 305: The OPT_TO_REG_OUTSIDE_LOCATION option in the "errors" select
mapping is missing terminal punctuation; update the OPT_TO_REG_OUTSIDE_LOCATION
message inside the "errors" string (symbol OPT_TO_REG_OUTSIDE_LOCATION) to end
with a sentence-ending punctuation mark (e.g., add a full stop "।" or "."
consistent with other Kannada messages) while preserving the surrounding select
syntax and quoting.
3 participants
RCF-1354
Summary by CodeRabbit
New Features
Behavior Changes
Localization
Strings
Tests
✏️ Tip: You can customize this high-level summary in your review settings.