David Smiley created SOLR-18605:
-----------------------------------
Summary: async=true should mean "fire and forget" (async without
tracking)
Key: SOLR-18605
URL: https://issues.apache.org/jira/browse/SOLR-18605
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Reporter: David Smiley
🤖 Some clients want to run an admin command asynchronously without ever polling
for its completion status. Examples: a cron job that triggers a backup, or a
shard split that will complete (or fail) eventually. Not every client can do
anything meaningful by polling. Today such a client must still supply a unique
{{async}} request ID per call, and Solr stores a status for it that nobody will
read; it lingers until cleaned up via {{DELETESTATUS}}.
h3. Proposal
Reserve {{async=true}} as a special value meaning "fire and forget":
* The command executes asynchronously and the response returns immediately, as
with any async request.
* No async ID is claimed in ZooKeeper, so repeated calls never collide.
* No result is stored, so there's nothing to clean up via {{DELETESTATUS}}.
* The response omits {{requestid}}.
{{async=false}} is treated as synchronous (i.e. as if {{async}} were absent).
h3. Scope
* Collections API, both Overseer and distributed modes ({{CollectionsHandler}},
{{DistributedCollectionConfigSetCommandRunner}}).
* CoreAdmin async ({{CoreAdminHandler}}).
* V2 APIs whose {{async}} request-body field flows through the same code paths.
* SolrJ: optionally a no-arg variant on {{CollectionAdminRequest}} (e.g.
{{processAsync()}} without an ID); could be a follow-up.
* Ref guide: async sections of the Collections API and CoreAdmin pages.
h3. Back-compat
Today {{true}} is treated as an ordinary request ID: the first call claims it,
and later calls fail with "Task with the same requestid already exists" until
it's deleted. Anyone relying on the literal ID {{true}} would lose the ability
to track it. That's unlikely, but worth a note in major-changes.
h3. Testing
Integration test: issue two {{async=true}} Collections API requests
back-to-back; both succeed, the work completes (e.g. wait for collection
state), and no request status is stored. Similar case for CoreAdmin.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
