Apollo release: updateCommand does not refresh commonName on an annotation-version bump

Gap

ApolloRelease::Commands::updateCommand sets directory, blatdb and publicMode, but not commonName. So an organism whose annotation version bumped keeps its old [sNN-mNN-rNN] suffix in Apollo indefinitely.

This is the one behaviour from Paul Wilkinson's createApolloReleasePackage_ALL.pl with no counterpart in the new package.

What the old script did

Paul's loop had three branches, keyed on matching the portal organism's name against Apollo's roster:

Branch 2 is the missing case. It fired on an annotation-version bump and refreshed the display name.

Note branch 2 did two jobs at once, in two files, with an undocumented ordering dependency: arrow set the name while passing back the old directory, and the curl set the directory to the new abbrev. Correct only if arrow runs before curl. The new tool's renameCommand already replaces that half properly — one atomic curl setting directory + blatdb + commonName against the reused Apollo id.

Coverage of everything else (no action needed)

Proposed fix

Not a new Apollo_arrow file. updateOrganismInfo already accepts commonName — renameCommand proves it. Add it to updateCommand via the existing apolloName($entry->{organism}); arrow then drops out as a dependency entirely.

Inputs are already in place:

• the update bucket carries organism, so latest_annotation_version is available
• $apollo->{common_name} is available in $live if we want to emit only on an actual difference

Open decision

Unconditional commonName on every update, or only where it differs from Apollo's stored name?

• unconditional — simpler, still idempotent
• conditional — keeps Apollo_curl diffable release-over-release, which is the property the fixed field ordering in _updateOrganismInfo exists to protect

Tests

Model/t/commands.t — assert updateCommand emits commonName, and (if conditional) that it is omitted when the name is unchanged. Note the existing password assertions only check that no literal password is baked in; they do not check field presence.

b71 status

Believed to have zero affected organisms, so this is not a b71 blocker — filing for the next release.

Unverified: the reconciliation report lists only abbrevs for the 453 updates, not common names, so confirming would mean diffing each Apollo common_name against apolloName($organism). Worth doing once before b72 to size the impact.

Start with ApolloRelease::Commands::updateCommand and the existing assertions in Model/t/commands.t; compare its emitted fields with renameCommand and the available apolloName($entry-> {organism}) input. Update the test to cover commonName emission and resolve whether unchanged names are omitted, then confirm the command output matches that decision.