Skip to content

0.22.2: every reopen of a log is given the stream's s3_options - #173

Merged
nhobin219 merged 1 commit into
release/0.22.xfrom
fix/reopen-s3-options
Oct 20, 2026
Merged

nhobin219 merged 1 commit into
release/0.22.xfrom
fix/reopen-s3-options

Conversation

@nhobin219

Copy link
Copy Markdown
Owner

Stream.new passed s3_options to litelink.new (create) but not to litelink.open (reopen), nor did migrate/retire/retain/revive/the retired open; a reopened log resolved credentials from the environment. A server whose streams publish to different stores could not restart after a stream's first publish (ACCESS_DENIED on its own metadata.json): seen in production, an office's message broker down on every restart.

Fix: every in-process litelink.open gets the stream's options (_metadata.complete too). Maintainers are unchanged (they get options via their environment).

New tests/test_reopen_credentials.py reproduces it against rustfs with the environment holding another key or none: fails before the fix with the production error, passes after; mutation (drop the options from _open_or_create only) fails both. With STREAMCAST_REQUIRE_S3=1: reopen_credentials, migrate, retention, restore, layout, process, published: 104 passed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PXyESUWnfYF3jXPHp7pz12

`litelink.new` got them and `litelink.open` did not, so a reopened log read
its published table with whatever key the environment held. A server whose
streams publish to different stores could not restart once a stream had
published: ACCESS_DENIED on its own metadata.json.

build: 0.22.2

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PXyESUWnfYF3jXPHp7pz12
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