Repository navigation
test: service writes give the same outcome for sync and async brokers - #6005
Merged
norman-abramovitz merged 5 commits intoOct 14, 2026
Merged
norman-abramovitz merged 5 commits into
norman-abramovitz merged 5 commits into
Conversation
Record Cloud Controller job responses from a live foundation, with a test broker answering synchronously and asynchronously and failing both ways, and replay them through the service instance, binding and key write handlers. Each write runs on the fast path and through the tracker handoff; both must report the same result, and broker failures the same error. The responses the frontend receives are kept in testdata/cf-jobs/stratos for its specs (-update rewrites them).
Answer the create-service-instance wizard's writes from the recorded backend responses instead of hand-written bodies, on the fast and the polled path, for a synchronous and an asynchronous broker. Known failures are marked: bind after create (cloudfoundry#6001) and broker failure messages that differ between the two paths (cloudfoundry#6002).
Answer binding create and delete, service key create and delete, and service instance delete from the recorded backend responses, for a synchronous and an asynchronous broker on the fast and the polled path, with the same assertions on each.
Run the create wizard against a test broker whose response mode can be switched (cloudfoundry/overview-broker, services.testBroker in the secrets profile), once synchronous and once asynchronous. The wizard must report success only once CF has the instance, and must bind the app chosen in the wizard; the bind case is a known failure (cloudfoundry#6001). Runs in one browser because the broker mode is shared.
This was referenced Oct 14, 2026
nabramovitz
added a commit
to nabramovitz/stratos
that referenced
this pull request
Oct 14, 2026
With the plural job link read, the wizard binds the chosen app for a synchronous and an asynchronous broker on the fast and the polled path, so the cloudfoundry#6001 expected-failure markers from cloudfoundry#6005 come off, in the unit spec and the e2e spec. The service write tests fragment no longer lists bind after create as a known gap.
norman-abramovitz
pushed a commit
that referenced
this pull request
Oct 14, 2026
With the plural job link read, the wizard binds the chosen app for a synchronous and an asynchronous broker on the fast and the polled path, so the #6001 expected-failure markers from #6005 come off, in the unit spec and the e2e spec. The service write tests fragment no longer lists bind after create as a known gap.
norman-abramovitz
pushed a commit
that referenced
this pull request
Oct 15, 2026
The same broker failure read differently depending on how CF answered.
Inside the fast-path window the message was the broker's detail; after
a polled job it was CF's title in front of it ("CF-UnableToPerform.
..."), and only the polled path removed the HTML page CF quotes from a
broker's response.
A failed job's message is now the detail, markup stripped, or CF's
title when there is no detail; extractHttpErrorMessage reads the
fast-path body the same way, through the same stripMarkup. Callers add
their own lead-in. The three expected failures from #6005 now pass.
Refs #6002
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
2 participants
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.
#6001 was not caught because the frontend spec and the backend translator test both used hand-written job fixtures with the same wrong link key. This PR replaces hand-written service-write fixtures with Cloud Controller responses recorded on a live foundation, and checks that a synchronous and an asynchronous broker give the user the same outcome on both resolve paths. It is meant to merge before #6004, which then drops the #6001 expected-failure markers together with its fix.
Recorded CF responses
src/jetstream/plugins/cloudfoundry/testdata/cf-jobs/cfholds real CF API 3.226 job bodies (first poll and terminal) for service instance create/update/delete, app binding create/delete and service key create/delete, with a test broker (cloudfoundry/overview-broker) in synchronous and asynchronous mode, plus broker failures: async create, async update, sync create. Hostnames are replaced withexample.com.Backend:
TestServiceWritesContractReplays each recording through the real write handler against a fake CF, twice: with the job already terminal (fast path,
200/502), and still running when the window closes (202handoff, then the tracker poll). Both paths must report the same result, and broker failures the same error. What the frontend receives is kept intestdata/cf-jobs/stratos;go test ./plugins/cloudfoundry -run TestServiceWritesContract -updaterewrites it.Frontend specs
@test-framework/cfgainsserviceWriteContract()andanswerServiceWrite(), which answer a pending write from those files on the fast or the polled path. The create-service-instance wizard (create, create + bind, update, broker failures), binding create, unbind, service key create and delete, and service instance delete each run for a sync and an async broker on both paths, with the same assertions.E2E
e2e/tests/marketplace/async-service-writes.spec.tsruns the wizard against the test broker switched to synchronous and to asynchronous responses: success is reported only once CF has the instance, and the app chosen in the wizard gets bound. Configure the broker asservices.testBrokerin the secrets profile (seee2e/secrets.yaml.template); the spec skips without it and runs in chromium only, since the broker's mode is shared. Live run: 6 passed (8.5 min).Known failures, marked
it.fails×4,test.fail×2it.fails×3CF-UnableToPerform. …)Finding for #6002
Every broker failure recorded (async create, async update, sync create) makes CF fail the job itself, so the polled path does report the failure; the "failure after the fast path reported as created" item in #6002 did not reproduce on CF API 3.226.
make check gatepasses. Changelog fragment:changelog.d/0007-service-write-tests.md.AI disclosure (RFC-0047): prepared with AI coding assistance; reviewed by the author.