Background
GRPCLoader.LoadFromTag initialises the catalog with an empty commit SHA:
// gitstore-api/internal/catalog/grpc_loader.go:41
cat := NewCatalog("", tag)
ListFilesResponse from the git-service already includes ref_commit_sha, but the loader discards it. As a result catalog.Commit() always returns "", which:
- Produces empty commit fields in cache-reload log lines (
zap.String("commit", ...) in cache/manager.go)
- Breaks any future client logic that expects a concrete commit hash for traceability or cache keying
Proposed fix
Capture ref_commit_sha from the first ListFiles response (all three prefix calls resolve to the same ref, so any one is sufficient) and pass it to NewCatalog:
cat := NewCatalog(refCommitSHA, tag)
Alternatively, call GetLatestTag (which already returns commit_sha on the TagEntry) and use that value directly in LoadFromLatestTag before delegating to LoadFromTag.
Acceptance criteria
catalog.Commit() returns a non-empty 40-char SHA after a gRPC-backed reload
- Existing unit and integration tests continue to pass
- Cache reload log line includes the resolved commit SHA
Identified during review of #122.
Background
GRPCLoader.LoadFromTaginitialises the catalog with an empty commit SHA:ListFilesResponsefrom the git-service already includesref_commit_sha, but the loader discards it. As a resultcatalog.Commit()always returns"", which:zap.String("commit", ...)incache/manager.go)Proposed fix
Capture
ref_commit_shafrom the firstListFilesresponse (all three prefix calls resolve to the same ref, so any one is sufficient) and pass it toNewCatalog:Alternatively, call
GetLatestTag(which already returnscommit_shaon theTagEntry) and use that value directly inLoadFromLatestTagbefore delegating toLoadFromTag.Acceptance criteria
catalog.Commit()returns a non-empty 40-char SHA after a gRPC-backed reloadIdentified during review of #122.