argoproj/argo-workflows

Pre-requisites I have double-checked my configuration I have tested with the :latest image tag (i.e. quay.io/argoproj/workflow-controller:latest) and can confirm the issue still exists on :latest. If not, I have explained why, in detail, in my description below. I have searched existing issues and could not find a match for this bug I'd like to contribute the fix myself (see contributing guide) What happened? What did you expect to happen? I upgraded to the following images quay.io/argoproj/workflow-controller:v4.1.2 quay.io/argoproj/argocli:v4.1.2 Now I get the following error from the controller and server: level=ERROR msg="failed to create initial database session: failed to create upper/db session: pq: no pg_hba.conf entry for host \"172.28.6.51\", user \"argo_test\", database \"argo_test\", no encryption (28000)" It seems very similar to #16707 but im using postges instead of mysql. Version(s) v4.1.2 Paste a minimal workflow that reproduces the issue. We must be able to ru

Pre-requisites I have double-checked my configuration I have tested with the :latest image tag (i.e. quay.io/argoproj/workflow-controller:latest) and can confirm the issue still exists on :latest. If not, I have explained why, in detail, in my description below. I have searched existing issues and could not find a match for this bug I'd like to contribute the fix myself (see contributing guide) What happened? What did you expect to happen? Summary When several controllers share a sync database, each controller's CheckWorkflowExistence garbage collector deletes the pending (held=false) state rows of every other controller, once a minute. The GC lists holder and waiter keys from the shared state table but checks them against the local informer only, so another controller's workflows always look deleted. RemoveFromQueue has no controller condition, so the delete goes through. Held rows survive because ReleaseHeld filters on controller, so mutual exclusion still works. Lock handover

Summary newInternalSemaphore in workflow/sync/semaphore.go#L44 (and similarly newDatabaseSemaphore in workflow/sync/database_semaphore.go#L46) currently fail to initialize a semaphore whenever its resolved limit is 0: var err error limit := sem.getLimit(ctx) if limit == 0 { err = fmt.Errorf("failed to initialize semaphore %s with limit", name) } return sem, err This means a semaphore can never start at 0, it must always be initialized with a limit greater than zero. We'd like this changed so that limit == 0 is treated as a valid initial state (a semaphore that currently permits zero concurrent holders), and initialization only fails for genuine errors resolving the limit (e.g. missing ConfigMap/key, or a parse error), not for a successfully resolved value of 0. Use Cases We want to build an "approval gate" for Workflows: a Workflow is created holding a synchronization.semaphore whose configMapKeyRef points to a per-workflow ConfigMap key initialized to 0. The workflow should stay b

Summary When we moved from logr to slog in #14644 we retained the ability for the logger to and exit(1) (fatal) from the legacy code. This was done for making the PR easier to digest. This is really not the responsiblity of the logger. Lets remove WithFatal from Logger in `/util/logging/logging.go that and replace each call to logger which used it with a call to os.Exit(1) afterwards. Acceptance criteria: WithFatal is gone from logging.go and all implementations of the logger Structural support for the flag (the withFatal flag) is gone. No tests except for /util/logging are changed Nothing much else changes Use Cases This is just a code improvement.