Device Registry Operations
OnePay● MediumFULLTIMEPHONE SCREENProblem statement
You maintain an in-memory registry of devices. Each device has an ID, a type, a current state, a registration time, a last-maintenance time, and a failure count.
The array typeStateRules defines which states are allowed for each device type. Each rule has the form type:state1|state2|.... Types are unique.
Process every string in operations in order. Each operation uses one of these formats:
REGISTER id type state registeredAt lastMaintenanceAt failureCountCOUNT_ACTIVEUPDATE now maintenanceAgeLimit failureLimit
Registration
A REGISTER operation succeeds only when all of the following are true:
- The device ID is not already registered.
- The device type appears in
typeStateRules. - The requested state is allowed for that type.
registeredAtis nonnegative.lastMaintenanceAtis at leastregisteredAt.failureCountis nonnegative.
Append OK when registration succeeds. Otherwise append REJECTED and leave the registry unchanged.
Active Counts
A COUNT_ACTIVE operation counts devices whose current state is exactly ACTIVE. Append the positive counts as comma-separated type=count entries in lexicographic type order. Omit types whose count is zero. If no device is active, append the empty string.
Batch Status Updates
For UPDATE now maintenanceAgeLimit failureLimit, inspect every registered device:
- If its failure count is at least
failureLimitandOFFLINEis allowed for its type, its target state isOFFLINE. - Otherwise, if
now - lastMaintenanceAtis at leastmaintenanceAgeLimitandMAINTENANCEis allowed for its type, its target state isMAINTENANCE. - Otherwise, its state does not change.
Failure-based updates therefore take precedence over maintenance-age updates. Append the number of devices whose state actually changed.
Return the appended outputs in operation order.
Function
processDeviceOperations(typeStateRules: String[], operations: String[]) → String[]Examples
Example 1
typeStateRules = ["sensor:ACTIVE|MAINTENANCE|OFFLINE","camera:ACTIVE|OFFLINE"]operations = ["REGISTER s1 sensor ACTIVE 10 10 0","REGISTER c1 camera ACTIVE 12 12 2","REGISTER s1 sensor ACTIVE 13 13 0","COUNT_ACTIVE","UPDATE 30 15 2","COUNT_ACTIVE"]return = ["OK","OK","REJECTED","camera=1,sensor=1","2",""]The first two registrations succeed, while the repeated ID s1 is rejected. Before the update, both devices are active. During the update, c1 becomes OFFLINE because its failure count reaches the threshold, and s1 becomes MAINTENANCE because its maintenance age is 20. No active devices remain.
Example 2
typeStateRules = ["sensor:ACTIVE|OFFLINE"]operations = ["REGISTER d1 sensor MAINTENANCE 0 0 0","REGISTER d2 camera ACTIVE 0 0 0","REGISTER d3 sensor ACTIVE -1 0 0","COUNT_ACTIVE"]return = ["REJECTED","REJECTED","REJECTED",""]The first registration uses a state that is not allowed for sensor, the second uses an unknown type, and the third has a negative registration time. All are rejected.
Example 3
typeStateRules = ["camera:ACTIVE","sensor:ACTIVE|MAINTENANCE|OFFLINE"]operations = ["REGISTER c1 camera ACTIVE 0 0 5","REGISTER s1 sensor ACTIVE 0 0 5","UPDATE 20 10 5","COUNT_ACTIVE"]return = ["OK","OK","1","camera=1"]Both devices meet the failure threshold, but camera does not allow OFFLINE, so only s1 changes state. The camera remains active.
Constraints
1 <= typeStateRules.length <= 50.1 <= operations.length <= 5000.- Every type appears in exactly one rule, and every rule lists at least one unique state.
- Device IDs, types, and states contain only letters, digits, hyphens, and underscores, with no spaces.
- Every operation has exactly the fields shown in its format.
- Every valid numeric field is between
0and10^9. - For every
UPDATE,nowis at least every registered device'slastMaintenanceAt.