zhisheng17/flink-learning · error · AlreadyExistException

{} already exists in ConfigMap {}

Error message

{} already exists in ConfigMap {}

What it means

KubernetesStateHandleStore.addAndLock() throws this when the key being added already exists in the ConfigMap and the caller holds leadership. It maps getKeyAlreadyExistException(key) through the completed transaction, signalling a duplicate state-handle insert under the same key.

Source

Thrown at flink-learning-k8s/flink-k8s/src/main/java/org/apache/flink/kubernetes/highavailability/KubernetesStateHandleStore.java:128

	public RetrievableStateHandle<T> addAndLock(String key, T state) throws Exception {
		checkNotNull(key, "Key in ConfigMap.");
		checkNotNull(state, "State.");

		final RetrievableStateHandle<T> storeHandle = storage.store(state);

		boolean success = false;

		try {
			final byte[] serializedStoreHandle = InstantiationUtil.serializeObject(storeHandle);
			success = kubeClient.checkAndUpdateConfigMap(
				configMapName,
				c -> {
					if (KubernetesLeaderElector.hasLeadership(c, lockIdentity)) {
						if (!c.getData().containsKey(key)) {
							c.getData().put(key, encodeStateHandle(serializedStoreHandle));
							return Optional.of(c);
						} else {
							throw new CompletionException(getKeyAlreadyExistException(key));
						}
					}
					return Optional.empty();
				}).get();
			return storeHandle;
		} catch (Exception ex) {
			throw ExceptionUtils.findThrowable(ex, AlreadyExistException.class).orElseThrow(() -> ex);
		} finally {
			if (!success) {
				// Cleanup the state handle if it was not written to ConfigMap.
				if (storeHandle != null) {
					storeHandle.discardState();
				}
			}
		}
	}

	/**

View on GitHub (pinned to d731cee761)

Solutions

  1. Check for the key first via check(name)/getAndLock, or delete the stale key before re-adding.
  2. Retry with a new unique key (state handles are usually keyed by job/checkpoint id — deduplicate on retry).
  3. Ensure leadership changed cleanly: a stale leader writing duplicate keys indicates a fence/lock problem in the ConfigMap lock identity.
  4. If this follows a crash, clear leftover job state (KubernetesRunningJobsRegistry/state store cleanup) before re-submitting the job.

Example fix

// before: blind add
stateHandleStore.addAndLock(jobKey, handle);
// after: guard against existing key
if (stateHandleStore.check(jobKey).isPresent()) {
    stateHandleStore.releaseAndTryRemove(jobKey);
}
stateHandleStore.addAndLock(jobKey, handle);
Defensive patterns

Strategy: validation

Validate before calling

// pre-check for an existing key before addAndLock
Optional<StoredStateHandle> existing = stateHandleStore.check(key);
if (existing.isPresent()) {
    stateHandleStore.releaseAndTryRemove(key);
}
stateHandleStore.addAndLock(key, handle);

Try / catch

try {
    stateHandleStore.addAndLock(key, handle);
} catch (Exception e) {
    if (e.getCause() != null && e.getCause().getMessage().contains("already exists")) {
        // stale key from a previous attempt — remove and retry once
    }
}

Prevention

When it happens

Trigger: addAndLock(key, stateHandle) called with a key whose value is already present in the ConfigMap while hasLeadership(c, lockIdentity) is true; the CompletionException wrapping it surfaces on .get().

Common situations: A retried job registration after a partially failed first attempt; stale leader re-adding a job state handle that a previous leader already stored; recovery/restart that re-runs the same key before cleanup.

Understand the failure class

Background: "already exists" / EEXIST / FileAlreadyExistsException: what the 'file already exists' error means and how to fix it — this error's family across 37 libraries.

Related errors


AI-assisted analysis of zhisheng17/flink-learning@d731cee761 (2026-09-06). Data as JSON: /api/errors/5e6d5e65ec9f82e3. Report an issue: GitHub.