We’re running Greengrass v2 on edge devices that maintain local device shadows for offline operation. After restarting Greengrass (either due to updates or device reboots), the local shadow state fails to sync back to the cloud shadow in IoT Core.
Before restart, devices were updating shadows locally and syncing to cloud successfully. Post-restart, the Greengrass logs show Shadow sync error: Version conflict messages. When we check the cloud shadow, it has an older version number than what the local shadow shows. This causes the device to reject cloud updates and the cloud to reject device updates.
Shadow sync configuration in the component recipe has shadowSyncEnabled: true and sync interval set to 30 seconds. We’re using named shadows for different device capabilities. The local shadow persistence seems to be working - shadow state survives restarts - but the version mismatch prevents synchronization. How should shadow sync handle device restarts to avoid version conflicts?
The shadow manager component syncs shadows but doesn’t resolve conflicts - it just reports them. You need to configure your component’s lifecycle to handle shadow reconciliation during startup. Add a bootstrap phase that checks shadow versions and resets if needed.
Also verify your local shadow persistence settings. If the local shadow database gets corrupted during restart, it might report incorrect version numbers. Check the Greengrass logs for any database errors during component initialization.
Shadow version conflicts after restart usually mean the local shadow version incremented while offline but the cloud didn’t receive those updates. When the device comes back online, both shadows have diverged. Check if your shadow sync component has conflict resolution configured - there should be a strategy for handling version mismatches (cloud wins, device wins, or merge).
I looked at the shadow sync component configuration and don’t see an explicit conflict resolution strategy setting. Is this something we need to implement in our application code or is there a Greengrass configuration option we’re missing?
Greengrass v2 shadow manager doesn’t have automatic conflict resolution built-in - you need to handle it in your component. The recommended approach is to implement a reconciliation strategy when your component starts:
- On startup, fetch the cloud shadow version
- Compare with local shadow version
- If versions differ, decide which state is authoritative based on your business logic
- Update the appropriate shadow to match
For most use cases, cloud shadow should be authoritative after restart since it represents the last known good state before the device went offline.