Greengrass Shadow Synchronization: Decide Which Offline Changes Win on Reconnect

An industrial gateway and its cloud application can edit the same shadow while disconnected. On reconnect, successful synchronization does not imply that the last wall-clock edit wins. Greengrass Shadow Manager has documented conflict rules that depend on synchronization direction and on whether the conflicting state is desired or reported.

Choose ownership before testing reconnection. This review uses the AWS Greengrass V2 shadow synchronization guide, checked on 19 October 2026. One-way direction selection requires Shadow Manager 2.2.0 or later. The examples use a disposable, application-owned named shadow with synthetic collector settings; no deployment or cloud update was performed.

Give desired and reported different meanings

For the proposed collector, desired intervalSeconds is the requested sampling interval. Reported intervalSeconds is the interval the application says it is currently using. A replica containing both members with different values can be informative: the application may not yet have accepted or applied the request.

Keep the evidence behind a reported value explicit. The synchronization service transfers document state; it does not measure the equipment or prove that an actuator changed. A component that copies desired values into reported values before validating them creates a misleading success signal even when synchronization works perfectly.

Use the exact application shadow name in the review. The Shadow Manager component reference requires selecting the shadows to synchronize. Its AWSManagedGreengrassV2Deployment shadow is service-reserved and must not be modified or deleted. A convenient existing shadow name is therefore not a suitable test target.

Work one offline conflict in both sections

Start the hypothetical fixture from synchronized values of desired 10 and reported 10 seconds. Disconnect the test gateway, then arrange these deliberately conflicting documents:

Local: desired.intervalSeconds = 8
       reported.intervalSeconds = 8
Cloud: desired.intervalSeconds = 20
       reported.intervalSeconds = 12

The cloud-side reported edit is an intentional conflict stimulus in this disposable fixture, not a recommended production writer. It makes both reconciliation directions observable.

For betweenDeviceAndCloud, AWS specifies cloud precedence for conflicting desired state and local precedence for conflicting reported state. Applying those rules to the fixture predicts desired 20 and reported 8 after reconciliation. That mismatch is the expected document result. It does not establish that the collector has begun sampling every 20 seconds.

Now make the application process the resulting desired state in a separate test phase. Record whether it accepts the value, what it actually applies and what it subsequently reports. Keeping reconciliation and application response separate prevents the test from hiding which component changed each field.

The same bidirectional conflict rule applies to versions before 2.2.0. Do not infer one-way capability merely because an older configuration contains a similarly named application setting.

Evaluate one-way modes as ownership choices

For deviceToCloud, conflicting cloud sections are replaced from the local document. The same synthetic fixture therefore predicts desired 8 and reported 8. Incoming cloud shadow updates are ignored by this synchronization direction. A cloud operator’s desired value cannot serve as the collector’s ordinary configuration channel under that assumption.

For cloudToDevice, conflicting local sections are replaced from the cloud document. The fixture instead predicts desired 20 and reported 12. Local updates are not sent to the cloud by this direction. Consequently, a cloud dashboard cannot treat that setting as a path for fresh locally reported observations.

These are consequences of the selected direction, not recommendations to make every gateway one-way. Write a producer-and-consumer map for each field before choosing. If cloud configuration and device reporting are both requirements of the same shadow, verify that the proposed direction supports both flows.

Keep synchronization timing separate from precedence

The component configuration distinguishes realTime from periodic synchronization. Periodic operation adds a configured delay in seconds; it does not redefine which side wins a conflict. Likewise, changing direction to reduce traffic changes ownership behavior, not merely the number of requests.

A review should therefore retain two independent decisions: when synchronization is attempted and which document side has authority for conflicts. A short interval cannot repair an unsuitable ownership rule. It can simply expose that unsuitable rule more often.

Do not use a shadow as the only record of every temporary setting entered during an outage. The proposed acceptance question is convergence of state. An audit requirement for every edit needs an explicitly designed event record with its own retention and delivery contract.

Capture the reconciliation result before enabling reactions

On an isolated test installation, pause any component that automatically applies desired settings, establish the synthetic conflict, restore connectivity and read both documents. Compare the result with the chosen rule. Then enable the application reaction and observe that distinct phase.

Retain component version, direction, strategy, exact shadow identity and the before/after values. Include a non-conflicting control case so a generic connection failure is not mistaken for a precedence defect. No test result is claimed here. The deliverable is a predictable reconciliation contract that the gateway application and cloud operator can both explain.