Let PROPERTY_DB point at Redis, not only at a directory - #8
Merged
Conversation
Core 0.3 shipped RedisCorpus — a corpus shared between CI and developers — and no suite could reach it. The engine reads no environment by design, so resolving where a corpus lives is this adapter's job, and this adapter hardcoded the filesystem one. PROPERTY_DB now takes redis://host[:port][/key-prefix] as well as a path, with the same parsing, defaults and messages as the Testo adapter, because the variable is one contract across both. ext-redis is preferred when loaded, predis otherwise, and neither installed throws rather than falling back: a suite told to share its corpus and quietly writing where nobody reads is worse than one that stops.
|
Important Review available on request
Reviews should be triggered manually for repositories with fewer than 10 stars. Select Trigger review above or comment ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Same fix as the Testo adapter, for the same reason: CI installs ext-redis and runs no Redis server, so an eager connect() in the resolver made every job red, while the composer image passed because it has no extension and predis is lazy by construction. The phpredis client is wrapped so the socket opens on the first recall or write, and two tests keep it honest — resolving a DSN returns without a server, and the documented preference is asserted in whichever environment the suite runs in.
Merged
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
1 participant
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.
The twin of
property-testing-testo#9— same variable, same DSN, same messages.Core 0.3 shipped
RedisCorpusand no suite could reach it: the engine reads no environment by design, so resolving where a corpus lives is the adapter's job, and this adapter hardcodedFilesystemCorpus::fromEnv(). Found while dogfooding 0.3 onrasuvaeff/circuit-breaker.Same document as the directory form, so a corpus moves between them by copying.
ext-redispreferred,predis/predisotherwise, and neither installed throws rather than falling back — a suite told to share its corpus and quietly writing where nobody reads is worse than one that stops.Parsing sits in its own
RedisDsn, which in the Testo adapter came out of a mutation finding: the default port and the predis parameter array were unobservable where they were built, and checking them meant connecting to a server.composer buildgreen: 83 tests, ~2.4k assertions; mutation 191/199, gate 90, nothing escaped in the new code. README (both languages),llms.txt,AGENTS.mdand CHANGELOG updated.