Edge Case: Move replication script generation logic into the scheduler
service (instead of the scheduler
client)
#117
Labels
bug
Something isn't working
This is an edge-case that doesn't happen very often, and is relatively easy to work around:
![image](https://private-user-images.githubusercontent.com/62173157/323360325-1835e7b2-058d-46c5-af13-fd25cf1a7085.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjUwNDQyNTUsIm5iZiI6MTcyNTA0Mzk1NSwicGF0aCI6Ii82MjE3MzE1Ny8zMjMzNjAzMjUtMTgzNWU3YjItMDU4ZC00NmM1LWFmMTMtZmQyNWNmMWE3MDg1LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MzAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODMwVDE4NTIzNVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPThlMzIwMWU0NjRkZjBlYTQ0YjkwNTgxYWZkMzY3ZTg3ZWYyYWUwYjJmMWI1OGQ3ZDM4MjkzMmZkMThjMDRiNjQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.uxDkSNQ4_Kjzi27pP1inn4BuuRWy6kt0Sqnmrna8Hok)
Because the logic of generating snapshots to be sent within a replication session is being executed on the
scheduler
client, it gets outdated by the next snapshot job in thescheduler
service' queue if the resource in question happens to be the same (VM/Jail with a same name and two separate scheduled jobs, added within a very short period of time from one another - the new snapshot gets taken and the old one is being deleted by the snapshot job, which changes the original snapshot list). The replication jobs fails in this case, because it can't physically find a snapshot that you told it to send. This is a rare scheduling/locking issue that I didn't account for in the beginning.The fix would be to move "generate snapshots to replicate" logic from the client to service. This way the service will be able to use a lock/mutex in order to prevent the unwanted data modification.
For now, the work-around is to simply re-run the replication once again (or wait for the next cronjob to kick in and do it for you). The bug is mostly "innocent" (and quite rare), as it can't damage any data on the receiving end.
The text was updated successfully, but these errors were encountered: