Repository navigation
fix: reject subscriber settings that delete data or never consume - #227
Merged
Merged
Conversation
Benchmark gate✅ gate passed
Gated (fails the build): |
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
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.
Closes #215. For 0.15.0: subscriber settings that would delete data or never consume now raise when the subscriber is registered.
What raises now
All checks run in
OutboxSubscriberConfig._validate, so every construction path goes through them:@broker.subscriber,@router.subscriberandOutboxRoute.max_deliveriesbelow 1 raisesValueError. Each row hasdeliveries_count >= 1by the time it's checked, so 0 put every row over the cap and deleted the queue (or sent it to the DLQ) without running the handler.Nonestill means no cap.min_fetch_interval,max_fetch_intervalorlease_ttl_secondsraisesValueError. NaN slipped past every<=check, and an infinite TTL brokemake_intervalin the fetch SQL.boolpassed as a count (max_workers,fetch_batch_size,terminal_flush_batch_size,max_deliveries) raisesTypeError.fetch_batch_size=Trueused to run as 1.str, or listed twice in one subscriber now raise. The messages and limits match the publish-side checks, so a subscriber can't listen on a name nothing can publish to.include_router(prefix=...)raisesValueErroron the broker and onOutboxRouter. The prefix used to be dropped silently, so a router ported from Kafka or Redis never consumed. The FastAPI router's HTTPprefixis unaffected, because it never reaches the broker.Default retry strategy after validation
The registrator used to fill in
ExponentialRetrybefore validation ran. As a result,ack_policy=REJECT_ON_ERRORwarned "retry_strategy is ignored" even when no strategy had been passed, and the "max_deliveries without retry_strategy" branch could never be reached. The config now validates the value as passed and fills in the default afterwards._default_retry_strategymoves toretry.pyso the config can call it.REJECT_ON_ERRORwith no strategy is silent. With an explicit active strategy it still warns.max_deliverieswarning now fires only forNoRetry(). With no strategy, the default retries, so the cap can be reached.test_fake.pythat suppressed the false warning no longer need to. Their suppressions are removed.Release note (0.15.0, breaking)
Tests
Each check has a test, and every test failed before the change except the guard that the default strategy is still applied. Docs updated:
docs/usage/subscriber.md(option table and validation paragraph) anddocs/usage/router.md(include_routerprefix).Verification
test_publish_with_activate_in_delays_deliveryon timing. It passed on the next two runs, and this change doesn't touch that path.just bench-checkpasses,ruffis clean,tyshows the same 6 diagnostics asmain, and the docs build.