Properly handle full and partial sync
MRs
- Implementation MR 1: Properly handle full and partial sync - Part 1 (!116475 - merged)
- Documentation MR: Add information about workspace updates (gitlab-org/remote-development/gitlab-remote-development-docs!21 - merged)
- Follow on part 2 issue to add test coverage for all scenarios: Add test coverage of rails_info config/version ... (#407160 - closed)
Why
Context - #396423 (comment 1316886168)
How
- Add 2 database fields -
desired_state_updated_at
andsent_to_agent_at
. -
desired_state_updated_at
is always updated to current time whendesired_state
is updated. -
sent_to_agent_at
is always updated whenever we respond to agent with information about the workspace. The information includesconfig_to_apply
orpersisted_deployment_resource_version
or both - For Full Sync, we will send information about all workspaces for that agent.
- For Partial Sync, we will send information about all workspaces for that agent using the filter
desired_state_updated_at >= sent_to_agent_at
, defined by the scopeWorkspace.with_desired_state_updated_more_recently_than_sent_to_agent
. - Regardless of Full or Partial Sync, we always echo back the persisted resource version of all workspaces that we received from agentk.
- Fetch from the DB for new/updated/deleted workspaces first and then save the information received from agentk to the DB. This is to ensure that a workspace which was updated by the user and agentk also sends an update about the same workspace in the upcoming poll.
Modelling of different scenarios that can occur for Partial Sync
Edited by Chad Woolley