π Pre-flight Checks
π Bug Description
First of all, thanks for engram β I have been using it daily as my memory
layer across a few projects, and it has become part of how I work.
While running the suite on Windows I ran into something in internal/sync
that I think is worth reporting.
FileTransport assumes syncDir resolves to a directory, so when it does not,
the failure surfaces later and in a shape callers cannot easily act on:
- If
syncDir does not exist, ReadManifest returns a file-read error
rather than an empty manifest, so a first-run client cannot tell "nothing has
been synced yet" from a real transport failure.
- If
syncDir exists but is a file rather than a directory, it is accepted,
and WriteManifest, WriteChunk and ReadChunk then fail with whatever the
OS returns for that path, which varies across platforms.
TestFileTransportReadManifestNotDir already covers the second case, and it is
currently red on my machine β I may well be missing something about how it is
meant to run, so please tell me if that is the case.
π Steps to Reproduce
go test ./internal/sync/... -run TestFileTransportReadManifestNotDir -v
β
Expected Behaviour
- A missing
syncDir yields an empty manifest (Version: 1), matching the
documented contract of ReadManifest.
- A
syncDir that is not a directory is rejected with a clear error.
β Actual Behaviour
--- FAIL: TestFileTransportReadManifestNotDir (0.00s)
transport_test.go:74: expected error when syncDir is a file
FAIL github.com/Gentleman-Programming/engram/internal/sync
π¦ Affected Area
internal/sync β FileTransport.
π Additional Context
I already have a candidate fix if it would help: a small validateSyncDir
helper called from ReadManifest, WriteManifest, WriteChunk and
ReadChunk. It propagates the os.Stat error unchanged so callers can use
os.IsNotExist to tell a missing path from one that is not a directory, and
ReadManifest maps the missing case to an empty manifest.
With it the existing test passes, and I add
TestFileTransportReadManifestMissingDir for the missing-directory path.
That said, you know the codebase far better than I do β happy to open a PR if
this is the direction you want, or to drop it entirely if there is a reason it
behaves this way. Just let me know either way, and thanks again for the project.
π Pre-flight Checks
status:approvedbefore a PR can be openedπ Bug Description
First of all, thanks for engram β I have been using it daily as my memory
layer across a few projects, and it has become part of how I work.
While running the suite on Windows I ran into something in
internal/syncthat I think is worth reporting.
FileTransportassumessyncDirresolves to a directory, so when it does not,the failure surfaces later and in a shape callers cannot easily act on:
syncDirdoes not exist,ReadManifestreturns a file-read errorrather than an empty manifest, so a first-run client cannot tell "nothing has
been synced yet" from a real transport failure.
syncDirexists but is a file rather than a directory, it is accepted,and
WriteManifest,WriteChunkandReadChunkthen fail with whatever theOS returns for that path, which varies across platforms.
TestFileTransportReadManifestNotDiralready covers the second case, and it iscurrently red on my machine β I may well be missing something about how it is
meant to run, so please tell me if that is the case.
π Steps to Reproduce
β Expected Behaviour
syncDiryields an empty manifest (Version: 1), matching thedocumented contract of
ReadManifest.syncDirthat is not a directory is rejected with a clear error.β Actual Behaviour
π¦ Affected Area
internal/syncβFileTransport.π Additional Context
I already have a candidate fix if it would help: a small
validateSyncDirhelper called from
ReadManifest,WriteManifest,WriteChunkandReadChunk. It propagates theos.Staterror unchanged so callers can useos.IsNotExistto tell a missing path from one that is not a directory, andReadManifestmaps the missing case to an empty manifest.With it the existing test passes, and I add
TestFileTransportReadManifestMissingDirfor the missing-directory path.That said, you know the codebase far better than I do β happy to open a PR if
this is the direction you want, or to drop it entirely if there is a reason it
behaves this way. Just let me know either way, and thanks again for the project.