Skip to content

fix: Find out again which API the server offers once it answers a path of the v2 API with 404 or 405, for example after a rollback. - #25

Merged
goloroden merged 3 commits into
mainfrom
ask-again-after-a-v2-404
Oct 19, 2026
Merged

goloroden merged 3 commits into
mainfrom
ask-again-after-a-v2-404

Conversation

@goloroden

@goloroden goloroden commented Oct 19, 2026 •

Copy link
Copy Markdown
Member

A client remembers whether the server offers the v2 API. After a rollback to a version without it, e.g. from 1.3 to 1.2, the server answers every path of the v2 API with 404 or 405, and until now every request failed until the client was created anew.

Now an answer with 404 or 405 to a request through the v2 API makes the client forget the API, so that the next request asks again:

  • This covers single answers, writes, schema registration, and streams, with or without the Server header of EventSourcingDB, as for the probe.
  • The request itself fails as before, and a write still ends with an OutcomeUnknownException.
  • A 404 through the v1 API, and an error that the v2 API reports with status 200, forget nothing.
  • TransportChooser gives each stored probe answer a generation under its lock. A request forgets only the answer it was sent under, so a late 404 leaves a running probe, and whatever a newer probe stored, even the v2 API again, alone.

The README gets one sentence in "Talking to Servers With and Without the v2 API". The tests in ProbeTest cover 404 and 405 for every authenticated request, a 404 without the header, the two cases that must not forget, a late 404 during and after a new probe, and a late 404 after a newer probe found out the v2 API again.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QykegdHe7vhHMBN3kWxgfH

…h of the v2 API with 404 or 405, for example after a rollback.

A client remembers whether the server offers the v2 API. A server that was
rolled back to a version without it, e.g. from 1.3 to 1.2, answers every path
of the v2 API with 404 or 405, so until now, every request failed until the
client was created anew.

Now, an answer with 404 or 405 to a request through the v2 API makes the
client forget the API, and the next request asks the server again. That holds
for single answers, writes, schema registration, and streams, and, as for the
probe, also for an answer that lacks the Server header of EventSourcingDB,
e.g. from a proxy that passes on the v1 API only. The request itself fails as
before, and a write still ends with an OutcomeUnknownException. A 404 through
the v1 API, and an error that the v2 API reports with status 200, forget
nothing.

TransportChooser forgets under its lock, and only a remembered v2 API, so
that a late 404 leaves alone a probe that is running, which other requests
share, and the v1 API that a newer probe found out.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QykegdHe7vhHMBN3kWxgfH
@goloroden
goloroden requested a review from a team as a code owner October 19, 2026 15:18
@goloroden goloroden self-assigned this Oct 19, 2026
goloroden and others added 2 commits October 19, 2026 17:21
…ver answers a path of the v2 API with 404 or 405.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QykegdHe7vhHMBN3kWxgfH
…late 404 keeps the v2 API that a newer probe found out.

Comparing the remembered API with the v2 API could not tell the answer that
a request was sent under from a newer one that names the v2 API, too. A
request whose 404 arrived after a new probe had found out the v2 API again
reset that answer, and the next request probed once more.

Each answer that a probe stores now has a generation of its own, counted
under the lock. A request carries the generation it was sent under, and its
404 or 405 forgets the answer only while that generation is still the one
remembered.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QykegdHe7vhHMBN3kWxgfH
@goloroden
goloroden merged commit a1a438e into main Oct 19, 2026
4 checks passed
@goloroden
goloroden deleted the ask-again-after-a-v2-404 branch October 19, 2026 17:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant