#2752 managedConfig: most CLI config writes exit 0 when the push to the datastore fails, leaving the change unpublished

Summary

Under managedConfig: true, most CLI commands that change config report success when their push to the remote datastore fails. The change is written to the local cache, the push error is logged as a warning, and the command exits 0. The operator believes the change is published, but it exists only on their machine, and no other instance ever sees it.

Commands don't agree on this: model create and model delete fail with a non-zero exit when their push fails, while the others exit 0.

Where it happens

All four push helpers in src/cli/managed_config_sync.ts catch the push error and only warn:

• pushManagedConfigChanges (line 59)
• pushManagedConfigChangesDeferred (line 88)
• pushManagedConfigPaths (line 141)
• pushManagedConfigPathsDeferred (line 174)

The deferred helper's doc comment says this is intended: a failure "warns but does not block the command".

Which commands are affected

Steps to reproduce

1. Set up a repo on @swamp/s3-datastore against a local emulator, then run swamp datastore config migrate.
2. Stop the emulator, or point the datastore at an endpoint that refuses connections.
3. Run swamp workflow create <name>, or swamp model edit <name> with new content piped in.
4. The command logs Failed to push managed config changes to remote datastore: ... and exits 0. The change is in the local cache's config/ tier and nowhere else.
5. Compare with swamp model create <type> <name> in the same state: it exits non-zero.

This was found by reading the source at swamp b4d6bad2. It has not yet been reproduced against a stopped emulator.

Expected

When a managedConfig push fails, every config-writing command:

1. exits non-zero;
2. keeps the local write (it is not rolled back);
3. says the change is saved locally but not published to the datastore, and names swamp datastore sync --push as the retry.

model create and model delete should give the same message, so all commands fail the same way.

Open question for the fix

The deferred helpers also catch a failure to resolve the datastore at all (the comment's example is a datastore extension that was just updated). That is still a change that was never published, so it should probably fail the same way. The fix should decide this explicitly.

Related

• The managedConfig UAT plan in swamp-uat has a test for this, MC-X2. It cuts the connection with a TCP proxy, asserts the non-zero exit, the swamp datastore sync --push hint and the kept local file, then retries with sync --push and checks the object reached the bucket. It will cover a command that uses the helpers (model edit or workflow create), not only model create.
• #2299 and #2337: the same "exits 0 with the data stranded" problem for workflow run data on the S3 datastore.