Scenario (agent-driven usage, jr 0.6.0-dev.10)
An automated workflow created an issue and immediately tried to look it up by JQL to run follow-up edits:
jr issue create -p MSSCI -t Task -s "review auto apps catalog for apps to add to self-service" --no-input
# printed: Created issue MSSCI-18654
jr issue list --jql "project = MSSCI AND summary ~ 'review auto apps catalog' AND created >= -1d" --output json
# returned: []
The empty result was Jira Cloud's eventually-consistent search index — the same query returned the issue seconds later. Not a jira-cli bug. But the empty result flowed into dependent commands as an empty key, producing a cascade of confusing errors (PUT /rest/api/3/issue/ 405, "At least one of 'id' or 'key' is required").
The correct usage existed the whole time: issue create --output json returns the key directly. The mistake was choosing the JQL round-trip. Filing this because the CLI is well-placed to compensate for that assumed usage rather than let it fail silently.
Suggestions (either or both)
-
Eventual-consistency hint on empty recent-window searches. When issue list --jql returns zero results and the query contains a short recency filter (e.g. created >= -1d or narrower), print a one-line note to stderr: search indexing on Jira Cloud can lag issue creation by seconds; just-created issues should be addressed by the key returned from issue create. Keeps stdout/JSON contract intact; turns a silent empty into a self-explaining one.
-
Opt-in retry for read-after-write workflows. Something like --retry-empty <N[,delay]> on issue list: if the result set is empty, retry up to N times with a short backoff before returning. Lets scripted callers that must search (e.g. dedup checks: "does a ticket with this summary already exist before I create one?") absorb index lag without hand-rolled sleep loops.
No change requested to issue create itself — --output json already covers the primary path; this is about making the wrong-but-natural pattern fail loudly or succeed.
Scenario (agent-driven usage, jr 0.6.0-dev.10)
An automated workflow created an issue and immediately tried to look it up by JQL to run follow-up edits:
The empty result was Jira Cloud's eventually-consistent search index — the same query returned the issue seconds later. Not a jira-cli bug. But the empty result flowed into dependent commands as an empty key, producing a cascade of confusing errors (
PUT /rest/api/3/issue/405, "At least one of 'id' or 'key' is required").The correct usage existed the whole time:
issue create --output jsonreturns the key directly. The mistake was choosing the JQL round-trip. Filing this because the CLI is well-placed to compensate for that assumed usage rather than let it fail silently.Suggestions (either or both)
Eventual-consistency hint on empty recent-window searches. When
issue list --jqlreturns zero results and the query contains a short recency filter (e.g.created >= -1dor narrower), print a one-line note to stderr: search indexing on Jira Cloud can lag issue creation by seconds; just-created issues should be addressed by the key returned fromissue create. Keeps stdout/JSON contract intact; turns a silent empty into a self-explaining one.Opt-in retry for read-after-write workflows. Something like
--retry-empty <N[,delay]>onissue list: if the result set is empty, retry up to N times with a short backoff before returning. Lets scripted callers that must search (e.g. dedup checks: "does a ticket with this summary already exist before I create one?") absorb index lag without hand-rolled sleep loops.No change requested to
issue createitself —--output jsonalready covers the primary path; this is about making the wrong-but-natural pattern fail loudly or succeed.