Why do I get an incorrect violation when I change a duty in the past?

From time to time we get a UAT issue reported by clients where they fail a rule on incorrect violation based on the scenario where the change is done to a duty in the past. Making changes to duties in the past is not advisable and specifically is not counted as a valid test scenario for compliance, due to the rules engine architecture where historical data (T-365 to T-3 days) is stored in the static cache. This cache is loaded once a day for a logged in user session, as this data is frequently re-used by the rules engine for the validation of the duty changes done on the day of operation and for future days. The data is stored as a static cache because of the unlikely scenario that past duties will need changes, so in a rare case where this is required any changes on the past data will result in the static cache being incorrect and only being refreshed on a fixed time interval not dependent on user action.

Operationally, users do not change past duties that are more than 2 days in the past. Operationally there are several reasons why this is not advisable except in exceptional circumstances:

1. Flight log records have usually been updated for these past duties so modifying the duties will change the official record of the flights in that duty which is not normally allowed.

2. Modification of past duties can have implications on payroll calculations and cause changes to duties that have already been paid in the latest payroll run.

3. Users have been know at some airlines to modify past duties to reduce duty and flight time to circumvent rolling flight and duty rules for a current duty. Therefore most clients restrict access to change past duties to supervisors only.

Therefore because users are not making changes to past data we architected the cache to be static for this past data to ensure performance rule checks without unnecessary reloading of the past data cache.