Greengrass Component Versions: Resolve Conflicting Thing and Thing-Group Requirements

Deploying a newer Greengrass component directly to one gateway does not necessarily override the version required by its thing group. Both targets can contribute requirements for the same component. If those requirements cannot be satisfied together, retrying the individual deployment does not resolve the contradiction.

For Greengrass V2, make a constraint ledger before changing recipes or group membership. The following examples use invented component names and versions. They are a review of satisfiability, not the results of an AWS deployment or an executed dependency solver.

Give every requirement an owner

The deployment guide describes version resolution across deployment requirements and recipe dependencies. Replacing a deployment for one target replaces that target’s prior revision; it does not erase an independent target’s requirement.

For each component under investigation, record the target or dependent component that supplies its constraint. Include the deployment revision or recipe version, the exact requirement, and whether it is still applicable to the gateway. Keep the actual component name as the join key. A friendly description such as “collector library” is insufficient when several packages perform related work.

Consider this synthetic ledger for com.example.TelemetryCodec:

Requirement owner                 Requirement
thinggroup/PackagingLab           exactly 1.4.0
thing/Gateway17                   exactly 2.1.0
Intersection                      empty

No version can equal both numbers. Downloading 2.1.0 successfully, extending an update timeout, or restarting a process cannot make that pair satisfiable. Preserve the conflicting owners in the error report so the responsible teams can decide which deployment definition should change.

Separate deployment versions from dependency ranges

The ComponentDeploymentSpecification API requires a component version. The recipe reference separately defines dependency VersionRequirement using npm-style semantic version constraints, which can describe a range. Do not paste a range into an exact deployment-version field because the ledger uses both kinds of notation.

A second synthetic case has two deployed applications depending on the codec:

Collector recipe:  >=1.4.0 <2.0.0
Uploader recipe:   >=1.6.0 <1.9.0
Shared interval:   >=1.6.0 <1.9.0

Version 1.7.2 fits both ranges. Version 1.9.0 does not, because the uploader’s upper bound is exclusive. If a third active target pins the codec to 1.4.0, the previously nonempty intersection becomes empty. Evaluate all applicable requirements together rather than approving each pair in isolation.

These ranges describe compatibility declared by the recipes, not evidence of application interoperability. A mathematically acceptable candidate still needs the product’s functional qualification.

Check that a satisfying candidate actually exists

A nonempty numeric interval is necessary but insufficient. The resolver also needs an available component version with the required recipe and platform compatibility. A version number that could exist is not an artifact that can be selected.

AWS documents different candidate-resolution paths for cloud and local deployments, including offline handling. Therefore this article does not predict that an isolated gateway always selects the newest cloud version. Record connectivity, deployment type and actual candidate availability when reviewing a resolution failure.

For the synthetic range case, make the distinction explicit: “1.7.2 satisfies the ledger if that version is an eligible available candidate.” If only 1.4.0 and 1.9.0 are available, the example has no usable candidate even though the theoretical interval contains other versions.

Prepare a coordinated change instead of a hidden override

Present the owners with the current ledger and the intended replacement ledger. An agreed migration might align both targets on a qualified version or update a dependent application’s compatibility declaration after testing. Neither choice should be inferred from which deployment was submitted last.

Do not silently remove the gateway from a group to eliminate a requirement. Membership can express other deployment responsibilities. Likewise, editing a configuration merge does not change the version constraint that prevented resolution.

A proposed qualification record should include an impossible exact-version pair, the compatible range example, and a nonempty range with no available candidate. Preserve the nucleus version, deployment identities, selected recipes and actual resolution outcome when those cases are eventually exercised.

The useful conclusion is precise: either one eligible version satisfies every applicable owner, or the ledger identifies the contradiction or availability gap. That gives the next maintenance decision a concrete basis before any component lifecycle is expected to run.