Preserve replaced message IDs
When a new message replaces several others, it inherits one of the IDs. The other IDs are added to the new wrapper, but:
- they are not stored in the cache database and thus do not survive a restart,
- they are silently dropped when the replacement message is updated again,
- they are immediately freed up (and could be reused), possibly causing confusion.
Number 1. and 2. cause issues similar to #45 (closed) for consumers which have cached the original messages but miss the first replacement message:
- T+00:00: A TraFF consumer application receives two TraFF messages, M1 and M2, from Qz, with a validity of 1 hour, and adds them to its cache.
- T+00:10: The TraFF consumer shuts down.
- T+00:20: Qz sends out a new message with the ID of M1, replacing also M2.
- T+00:25: Qz sends out another update for M1.
- T+00:30: The TraFF consumer starts up again and polls all TraFF sources for cached messages.
Currently, the message sent at T+00:25 would no longer refer to M2. The TraFF consumer would update M1 with the latest version but would never update M2, keeping a stale version of it until it expires.
The approach to fix this would be:
- Ensure replacement messages inherit not only the IDs of messages they replace, but also the IDs of any messages these messages might have replaced.
- Store IDs of replaced messages in the database.
- Keep replaced IDs marked as being in use until the last replacement message expires.