Conversation
Completed Working on "Code Review"✅ Workflow completed successfully. |
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Files
|
|
Important Review skippedBot user detected. To trigger a single review, invoke the You can disable this status message by setting the
Comment |
There was a problem hiding this comment.
Review summary
- BLOCKER: 0
- CRITICAL: 0
- MAJOR: 1
- MINOR: 0
- SUGGESTION: 0
- PRAISE: 0
Key themes
- The redis client jump to 7.1.0 changes the async connection-pool internals that power FalkorDB bootstrap, yet we have zero test coverage exercising those redis paths, so we could ship a silent regression.
Next steps
Add an integration/regression test that instantiates the redis/FalkorDB connection (fakeredis or live) and proves the async pool still works on 7.1, or keep redis pinned to 6.4.0 until that coverage exists.
| "markers": "python_version >= '3.9'", | ||
| "version": "==6.4.0" | ||
| "markers": "python_version >= '3.10'", | ||
| "version": "==7.1.0" |
There was a problem hiding this comment.
[major]: Redis client bump lacks coverage
@@ Pipfile.lock:2303 @@
"redis": {
"markers": "python_version >= '3.10'",
"version": "==7.1.0"
}
This lock refresh upgrades redis from 6.4.0 to the 7.x line, which changes the async client internals that power redis.asyncio.BlockingConnectionPool in api/extensions.py for every FalkorDB connection, yet the test suite never touches redis/fakeredis (no occurrences under tests/). Without any automated coverage the upgrade could silently break cache/bootstrap flows and would only surface in production. Please add a regression/integration test that instantiates the redis connection (e.g. via fakeredis or a FalkorDB container) and exercises the path, or pin redis back to 6.4.0 until such a test exists.
Suggested fix: Add a test under tests/ that imports api.extensions.db (or uses fakeredis) and verifies a query succeeds through redis.asyncio.BlockingConnectionPool, or keep redis pinned to 6.4.0 until that coverage exists.
| "markers": "python_version >= '3.9'", | ||
| "version": "==6.4.0" | ||
| "markers": "python_version >= '3.10'", | ||
| "version": "==7.1.0" |
There was a problem hiding this comment.
Bumping redis to 7.1.0 is more than a patch update: 7.x reworked the asyncio connection pools (redis.asyncio.BlockingConnectionPool) that we use in api/extensions.py to bootstrap every FalkorDB connection. Our current test suite never exercises those redis/fakeredis paths (no tests reference redis at all), so this change could introduce regressions that only show up in production when the async pool semantics diverge. Please either (1) add an integration/regression test that instantiates the FalkorDB redis connection (fakeredis or a live container) and proves queries still succeed on 7.1, or (2) keep redis pinned at 6.4.0 until we have coverage. Without one of those safeguards we have no signal that the upgrade is safe.
de9e940 to
3458b0f
Compare
Bumps [falkordb](https://github.com/falkorDB/falkordb-py) from 1.2.2 to 1.4.0. - [Release notes](https://github.com/falkorDB/falkordb-py/releases) - [Commits](FalkorDB/falkordb-py@v1.2.2...v1.4.0) --- updated-dependencies: - dependency-name: falkordb dependency-version: 1.4.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
3458b0f to
a6fa53f
Compare
Bumps falkordb from 1.2.2 to 1.4.0.
Release notes
Sourced from falkordb's releases.
Commits
fe85af5Merge pull request #145 from FalkorDB/gkorland-patch-15f4bb8cUpdate pyproject.toml4ba3271Update test.yml90dfb98Update dependencies versions0f04009Merge pull request #102 from wilhelmagren/tests/improve-coverage46f804fRemove unnecessary string equality assertion292c810Update test_path.py5534d24Fix path string representation in testf4b92c3Update test_path.py357e19eMerge branch 'main' into tests/improve-coverageDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)