Sync profiles cannot pass query/filter parameters to POST-based list actions

[ameet]

Problem

Sync profiles only support queryParams and pathVars for passing parameters to list actions. When the list action is a POST endpoint (like Gmail List Threads - GGSNlnppgZ0), the query parameter needs to be in the request body, not a URL query parameter.

The sync framework sends queryParams as URL params regardless of HTTP method. POST actions that read from the request body never see the filter, and return unfiltered results.

Example

Gmail sync profile:

{
  "actionId": "conn_mod_def::GGSNlnppgZ0::qk3CudDWTVKPY7hpPVCqLQ",
  "queryParams": {
    "q": "subject:\"Portfolio Company Updates\" newer_than:2y"
  }
}

The action expects:

POST /gmail/get-threads
Body: {"query": "subject:Portfolio Company Updates", "numberOfThreads": 50}

But the sync sends:

POST /gmail/get-threads?q=subject%3A%22Portfolio+Company+Updates%22+newer_than%3A2y
Body: {} (empty)

The query is ignored. The action returns its default (most recent 10 threads regardless of filter).

Requested fix

Add a body field to sync profile schema so POST-based list actions can receive their filter parameters correctly.

Related

withoneai/knowledge#65 — Gmail actions not returning filtered results

[ameet]

Root cause found: Server returns 500/502 when sync runner sends body params

We built the One CLI from source, added debug logging to the sync runner, and confirmed:

1. The sync runner DOES read profile.body and sends it correctly:

   [sync-debug] page=0 hasBody=true bodyKeys=["connectionKey","query","numberOfThreads"] queryKeys=[]
   

2. But the server returns 500/502:

   Server error (500). Waiting 5s before retry (1/3)...
   Server error (502). Waiting 10s before retry (2/3)...
   Server error (500). Waiting 20s before retry (3/3)...
   

3. The SAME action with the SAME body works perfectly from actions execute:

   one --agent actions execute gmail GGSNlnppgZ0 $KEY \
     -d '{"connectionKey":"...","query":"subject:Portfolio Company Updates","numberOfThreads":5}'
   # Returns 5 threads correctly

The profile body field support is implemented correctly in the CLI. The issue is that the passthrough API (executePassthroughRequest) sends the request in a way that causes the Pica Composer backend to return 500/502, while the actions execute path sends it differently and succeeds.

Likely differences between the two paths:

• Different Content-Type headers
• Different URL construction
• Different request signing or authentication headers
• The sync runner may be sending extra headers/params that confuse the Pica backend

This is a server-side issue in the One passthrough API, not a CLI bug. The CLI code is correct.