Steps to reproduce

1. Have a running Drasi environment.
2. Define a source and a query in separate YAML files (e.g., my-source.yaml, my-query.yaml).
3. Apply the source: drasi apply -f my-source.yaml.
4. Apply the source a second time: drasi apply -f my-source.yaml. Observe that it completes successfully.
5. Apply the query: drasi apply -f my-query.yaml.
6. Verify the query is running with drasi list query.
7. Apply the query a second time: drasi apply -f my-query.yaml.
8. Observe the error.

Observed behavior

The command fails with a 500 Internal Server Error.

✗ Error: Apply: ContinuousQuery/delivery: 500 Internal Server Error : Internal server error
Error: 500 Internal Server Error : Internal server error

Desired behavior

The second drasi apply for the query should succeed, indicating that the resource is unchanged, similar to the behavior for sources.

✓ Apply: ContinuousQuery/my-query: complete

Workaround

None

Drasi Version

Latest

Operating system

No response

Additional context

Contribution Guide

The investigation should start in the control-planes/mgmt_api service, which handles the backend logic for the apply command.

1. Look at the PUT handler for continuous queries in the mgmt_api. It's likely in a file like src/api/continuous_queries.rs.
2. Compare the logic for creating/updating a query with the equivalent handler for sources. The source handler likely has better logic for checking if the resource already exists and handling it gracefully.
3. The goal is to make the query PUT endpoint behave idempotently, just like the source endpoint.

Logs

CLI Commands

@amansinghoriginal ➜ .../learning/tutorial/curbside-pickup/drasi (main) $ drasi list source
       ID      | AVAILABLE | MESSAGES  
---------------+-----------+-----------
  retail-ops   | true      |           
  physical-ops | true      |           
 @amansinghoriginal ➜ .../learning/tutorial/curbside-pickup/drasi (main) $ drasi apply -f physical-ops-source.yaml 
✓ Apply: Source/physical-ops: complete
 @amansinghoriginal ➜ .../learning/tutorial/curbside-pickup/drasi (main) $ drasi list query
     ID    | CONTAINER | ERRORMESSAGE |              HOSTNAME              | STATUS   
-----------+-----------+--------------+------------------------------------+----------
  delivery | default   |              | default-query-host-57c7796d5-m5pbq | Running  
  delay    | default   |              | default-query-host-57c7796d5-m5pbq | Running  
 @amansinghoriginal ➜ .../learning/tutorial/curbside-pickup/drasi (main) $ drasi apply -f delivery.yaml 
✗ Error: Apply: ContinuousQuery/delivery: 500 Internal Server Error : Internal server error
Error: 500 Internal Server Error : Internal server error

Management API Logs

• First apply (Success):

   1     [2025-09-27T20:12:57Z INFO  mgmt_api::domain::resource_services::standard] Setting resource: delivery
   2     ...
   3     [2025-09-27T20:12:57Z INFO  actix_web::middleware::logger] 127.0.0.1 "PUT /v1/continuousQueries/delivery HTTP/1.1" 200 ...

The first apply command is received, processed, and returns a 200 OK.

• Second apply (Failure):

   1     [2025-09-27T20:13:26Z INFO  mgmt_api::domain::resource_services::standard] Setting resource: delivery
   2     ...
   3     [2025-09-27T20:13:26Z ERROR mgmt_api::domain::resource_services::standard] Error configuring resource: GrpcError(GrpcError { 
     ... message: "error invoke actor method: error from actor service: (409) Query already configured" ... })
   4     ...
   5     [2025-09-27T20:13:26Z INFO  actix_web::middleware::logger] 127.0.0.1 "PUT /v1/continuousQueries/delivery HTTP/1.1" 500 ...

When the second apply is received, the mgmt-api attempts to configure the resource, but it immediately receives a gRPC error back from the Dapr actor invocation. The error message is the key: (409) Query already configured. The mgmt-api then correctly translates this internal failure into the 500 Internal Server Error that we see in the CLI.

Query Host Logs

• First configure call (Success):

   1     [2025-09-27T20:12:57Z INFO  query_host::query_actor] Request for actor_type: default.ContinuousQuery, actor_id: delivery
   2     [2025-09-27T20:12:57Z INFO  query_host::query_actor] Query configure - delivery
   3     ...
   4     [2025-09-27T20:12:57Z INFO  query_host::query_actor] Query delivery configured

The actor receives the configure request and proceeds to set up and run the query.

• Second configure call (Failure):

   1     [2025-09-27T20:13:26Z INFO  query_host::query_actor] Request for actor_type: default.ContinuousQuery, actor_id: delivery
   2     [2025-09-27T20:13:26Z INFO  query_host::query_actor] Query configure - delivery
   3     [2025-09-27T20:13:26Z ERROR query_host::query_actor] Query delivery already configured

When the actor receives the exact same configure request again a second time, it hits a condition where it checks if the query is already configured, and instead of panicking, it logs a controlled ERROR message: Query delivery already configured. This error is then returned to the mgmt-api, causing the failure.

Would you like to support us?

• Yes, I would like to support you