Repository navigation
Async service operations: remaining gaps after the v3 job tracker #6002
Description
Stratos follows CF v3 async jobs for service instances, bindings, keys and route bindings (the stratosjobs tracker,
fast path then polling, and writeWithJob in the frontend). What is left:
- Broker failure after the fast path.
last_operationis re-checked only when the CF job finishes within the
3-second fast path. A slower broker that fails is reported as created/updated, because a COMPLETE job is taken
as success. Re-checklast_operationon the polled path too (create and update). - Unbounded wait. The wizard's poll has no ceiling; with a slow broker the Next button spins until the job
ends. Hand off after a bounded wait: return to the services list with an "in progress" notice. - UNKNOWN reported as success. If the job tracker loses the job (another replica, restart) or a poll errors,
the result isUNKNOWNand the UI says "created"/"deleted". Say the outcome is unknown and point to the list. - No refresh while in progress. Service lists and the instance detail page never refresh while an
operation is in progress, and create/update don't invalidate the cached lists
(cascade-registry.ts:serviceInstance.create/updatemap to[]). Poll while any row is in progress. - Little operation detail. Lists show only the state pill; the detail page shows state and description but
not the operation type. Show type and, on failure, the broker's description. - Bindings and keys don't re-check
last_operationafter their jobs complete. - Dead code.
LongRunningCfOperationsServiceandServiceInstanceLastOpComponenthave no callers. - E2E. The async provisioning tests in
e2e/tests/marketplace/are placeholders that assert nothing.
The lab's on-demand broker (valkeystandalone) provisions asynchronously and can back real tests.
Activity
nabramovitz commentedon Oct 14, 2026
Update from recording real Cloud Controller responses (CF API 3.226) with a test broker failing in each mode (#6005):
FAILED,CF-UnableToPerformwith the broker's detail). Stratos therefore reports the failure on the polled path as well as the fast path. No "job COMPLETE, instance failed" case came up; the fast-pathlast_operationre-check stays as a guard.Failed to create service instance: <detail>, while the polled path showsFailed to create service instance: CF-UnableToPerform. <detail>. test: service writes give the same outcome for sync and async brokers #6005 marks this as an expected failure (create and update) so the fix can drop the marker.test(services): wizard outcome for sync and async brokers
nabramovitz commentedon Oct 14, 2026
Plan update, and one stretch goal.
The items above will land as a few PRs, starting with the error message: every service write will report a broker failure the same way on both paths, a short lead-in from Stratos followed by the broker's own explanation. The CF error code moves to the browser console when there is a broker explanation to show, and stays in the message when there is not.
Stretch goal, not committed to this issue yet: CF quotes a broker's raw response in the job's error detail, so a router or proxy error page arrives as HTML. Today Stratos removes every tag and keeps all the text. That loses the structure that carried the meaning (a heading and its explanation run together) and can keep text that was never meant to be read, such as a page title or inline CSS.
The idea is for the backend to parse that HTML, unwrap the page layers, drop the head, scripts and styles, and pass the message on as text with simple styling (a heading becomes a bold first line, paragraphs become line breaks). The frontend would only ever set text, so no broker markup reaches the browser. Links would keep their text but not their target. Anything the parser does not recognise falls back to today's full stripping.
The plan is to collect real error bodies while working on this issue (gorouter, nginx, HAProxy, Envoy, cloud load balancers, and the default error pages of common app servers), each with its expected output, as test cases. Once the common cases are covered we will decide whether this belongs here or in its own issue, since it affects every place that shows upstream error text, not only service operations.
fix(services): report a failed write by its detail
feat(services): log the CF code of a failed write
fix(services): name the reason when a write fails
fix(jobs): answer a failed fast-path job as 422
fix(cf): show the endpoint banner for endpoint faults
fix(cf): name failed items in bulk summaries
feat(services): ask before handing off a slow write
fix(jobs): back off job polls exponentially
feat(services): follow a handed-off write across reloads
fix(services): bring the slow-write question into view
fix(cf): give CF's detail for a bulk item that fails fast
feat(config): set how long the browser follows a job
100 remaining items
test(e2e): wait for a handed-off bind's toast
test(e2e): check the services list at /services
test(e2e): drop unused marketplace page objects
docs(changelog): note the form error and https fixes
fix(core): reuse the root route on first navigation
test(e2e): read the offering header directly
test(e2e): share the test broker instance maker
test(e2e): test an offering's tabs with real content
docs(changelog): note the first-navigation rebuild fix
test(e2e): test the CF endpoint and section for real
fix(core): render a dialog before it is painted
test(e2e): read the API key dialog buttons with retries
test(e2e): wait for the app shell, not network idle
norman-abramovitz commentedon Oct 20, 2026
All items are done. Where each one landed:
last_operationre-check stays as a guard. The item that comment added, the error message differing by path, is #6016.ASYNC_JOB_TRACKING_LIMIT_IN_MINS.last_operationafter the job completes, for bindings and keys as for instances.LongRunningCfOperationsServiceandServiceInstanceLastOpComponentremoved.