Repository navigation
fix: track() returns created Path on success (match Optional[Path] signature) - #2
Merged
Merged
Conversation
The signature `-> Optional[Path]` promises a Path on success, but all three failure paths return None explicitly while the success path falls through, returning None implicitly. Library callers cannot distinguish success from failure via the documented return type. Adds `return filepath` on the success branch and a test asserting the return is a valid Path. Failure-path None returns are preserved, so existing assertions (empty name, whitespace name, duplicate tracking) are unchanged. Co-Authored-By: Claude Opus 4.6 <[email protected]>
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.
Summary
MemKraft.track()declares-> Optional[Path]but the success path never returns the createdPath— it falls off the end of the function and implicitly returnsNone. Callers that use the documented return type cannot distinguish success from failure. This PR adds the missingreturn filepathon success.Problem
In
src/memkraft/core.pythetrack()method declares:All three failure paths return
Noneexplicitly:return Nonereturn NoneOSErrorwriting filereturn NoneBut the success path ends at the print statement on line 125 and falls through, returning
Noneimplicitly — so the signature's promise ofOptional[Path]is only ever a promise ofNone.Fix
One line:
filepath.write_text(content, encoding="utf-8") print(f"✅ Tracking: {filepath.relative_to(self.base_dir.parent)}") + return filepath except OSError as e:Why it matters
name(duplicating_slugify+live_notes_dirlogic), or ignore the return entirely.Nonereturns on failure paths are preserved, so nothing downstream breaks.f407429("R11 hotfix — return values, …") already swept similar gaps elsewhere; this looks like one that slipped through.Test plan
TestR16DuplicateEntities::test_track_new_returns_pathwhich asserts the return valueisinstance(result, Path), the file exists, and the path equals the expectedlive_notes_dir / slug.Noneon failure are unchanged and still pass (test_track_duplicate_returns_none,test_track_empty_name,test_track_whitespace_name).pytest tests/), up from 277.Scope
This PR touches only
track()'s success return and adds one test. No behavior change for any failure path, no refactor, no new dependencies.🤖 Generated with Claude Code