Repository navigation
Conversation
Async service operations run as CC jobs with no CLI-visible handle. When a command returns before the job finishes (no --wait provided), print the job GUID so users and operators can trace it via 'cf curl v3/jobs/<guid>' which is the only key to that job's status and warnings.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note: This PR targets
main. Backport for v8: #3877.Description of the Change
Async service operations (create/update/delete/bind/unbind, and their keys) are carried out by a Cloud Controller job. The CLI has no first-class concept of a job - there is no
cf jobscommand - so once a command returns on the no-wait path, the user has no handle to the operation that is still running server-side. The job GUID is the only identifier that lets anyone inspect that work (viacf curl v3/jobs/<guid>), and today it is shown only when a job fails or times out (JobFailedError,JobTimeoutError).This change surfaces the job GUID on the in-progress path as well. When a service command returns while the operation is still running (no
--wait), it now prints an extra line after the existing status hint:Implementation:
JobGUIDfield toPollJobEventat both theccv3andv7actionlayers, mirroring howState/Err/Warningsare already threaded through those two structs. It is populated from the already-existingccv3.Job.GUID.shared.WaitForResultnow returns the observed job GUID:(bool, error)→(bool, string, error)(internal helper, not a user-facing CLI change).shared.DisplayJobHint(ui, jobGUID)helper that printsJob (<guid>) is being processed.and no-ops on an empty GUID.bind-route-service,bind-service,cleanup-outdated-service-bindings,create-service,create-service-key,delete-service,delete-service-key,unbind-route-service,unbind-service,update-service,upgrade-service.The hint is deliberately emitted per call site rather than centrally inside
WaitForResult, because it is interleaved with each command's own command-specific text (e.g. theTIP: ...restageline inbind-service) and becausedelete/delete-org/delete-spaceintentionally do not show it. Those three delete commands always wait to completion (no no-wait path), so they only pick up the new return signature (_, _, err) and print nothing new.No new flags, no reworded or removed existing output, and warning de-duplication behavior is unchanged.
Why Is This PR Valuable?
With recent CF API changes, service deletions and other async operations can take significantly longer depending on the service broker. Users increasingly hit "is it even being processed?", "why is it taking so long?", and "why did it fail?" - and the returned error alone is often not enough. The job GUID is the single traceable key to that information. It also helps operators: when a user reports "a command hangs forever" without
-vlogs or resource GUIDs, the job GUID is frequently the only thread an operator has to trace the operation in Cloud Controller.Applicable Issues
How Urgent Is The Change?
Not urgent. Quality-of-life / supportability improvement.
Other Relevant Parties
CF operators who triage long-running or stuck service operations; users of the service lifecycle commands listed above.
Note: this PR was developed with AI assistance, with manual review and testing by the author.