Argo-cd: Creating application via API doesn't support upsert flag

[der-eismann]

Describe the bug

The "create application endpoint" (example.com/swagger-ui#operation/Create) doesn't support the upsert flag even though the error message suggests it does. Not sure why an application is handled differently than a project here.

To Reproduce

1. Create an ArgoCD application
2. Send an application manifest with the same name but different spec via POST to the /api/v1/applications endpoint
3. Get the following output:

{
    "error": "existing application spec is different, use upsert flag to force update",
    "code": 3
}

Expected behavior

I expect an upsert flag on this endpoint, just like the "create project endpoint" (example.com/swagger-ui#operation/CreateMixin5).

Version

v1.5.1+8a3b36b

[jannfis]

I think it's rather the project endpoint that is faulty here, I don't know why the POST method should have an upsert parameter, while the endpoint also provides a PUT handler for updating a project. The same goes for the application endpoint, you should be able to send your changed manifest using the PUT verb for updating an existing application.

I agree that the error message is misleading. I guess it is intended to be displayed in the CLI, so that the user is reminded to use the --upsert flag.

[der-eismann]

you should be able to send your changed manifest using the PUT verb for updating an existing application.

Yes, that works fine, but I can't use the PUT verb if the application doesn't exist yet - and upsert means insert or update, whatever fits. It would take some work off the user because right now I have to check if the application already exists instead of just sending "upsert": true, but I understand your position as well. Either way, it should be consistent on all the endpoints.

[jannfis]

I have just had a look at the protobuf source files for both, application and project services, and they both actually define an upsert parameter. The difference being that for application service, the parameter is marked as optional, and for the project service it's not.

Have you actually tried to pass an additional upsert parameter in your POST request to application service?

I have seen in the past that the swagger files do not contain all possible parameters (e.g. #3428), even though the API accepts them. I think there is something fishy about the protobuf/grpc-gateway/swagger-generator combination currently, which we have to take a deeper look at.

[der-eismann]

Yes, I tried to add an upsert parameter, but it didn't help.

I haven't worked with RPC/protobuf yet, but could it be that the application service explicitly expects an application object as its body while the project service just expects an *?

"Fixing" this would be a breaking change since it currently accepts an application object directly. In the project service it is nested inside a project object.

[alexmt]

Actually POST /applications API supports upsert flag. Unless I'm missing something it should be passed as a query parameter e.g. POST /applications?upsert=true. I agree, this is inconsistent with projects API.

[der-eismann]

POST /applications?upsert=true does work indeed, interesting.

[jannfis]

I think this is a real bug and should be fixed, but as @der-eismann suggested, a "good" fix would be breaking the API and therefore we should do it only with the next major version, i.e. v2.0.