Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

test(store): same-second project tombstone regression test can pass without asserting its timestamp boundary

Closed
  • Is something wrong?
#1,897 3 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@tony-mejia is already working on this.

Since Oct 16, 2026.

  • #1918 by @dnlrsls — merged

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
70/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go, sqlite
Domain
databases, testing

Research direction

Start with TestDeleteProjectTombstoneKeepsSameSecondPostDeleteMutationPending in internal/store/project_delete_tombstone_test.go, and note how it reads occurred_at and deleted_at. Reproduce by inserting the 1.1s sleep between the hard delete and the post-delete enqueue, and check the timestamp precision the store writes. Done means the test derives the boundary from the mutation's own occurred_at, asserts occurred_at > deleted_at within one second, and fails on second-precision stamping while passing on the current head.

Written by the indexing model from the issue text.

Description

status:needs-review type:bug
Existing Issue Search
  • I searched existing issues and will add evidence to a canonical tracker when applicable.
📝 Observed Consequence

The regression test introduced for the sub-second project-tombstone fence —
TestDeleteProjectTombstoneKeepsSameSecondPostDeleteMutationPending in
internal/store/project_delete_tombstone_test.go (PR #1895) — asserts mutation dispositions
only. Nothing in it asserts the timestamp boundary it is named after, and the same-second
collision it depends on is left to the wall clock. When the post-delete enqueue lands in a
later second than the tombstone's deleted_at, every assertion still holds for a reason
unrelated to the behaviour under test: the test reports a pass while occurred_at carries
only second precision. A regression back to the second-precision column default can go
green.

🔄 Steps to Reproduce
  1. Check out the head of PR #1895 (a517487).
  2. Restore second-precision stamping: git checkout dd7fb2bc -- internal/store/store.go
  3. Keep the merged test body unchanged and insert a wall-clock gap between the hard delete
    and the post-delete enqueue (a slow or loaded machine does this on its own):
    time.Sleep(1100 * time.Millisecond)
  4. Run: go test ./internal/store/ -run '<the merged test>' -count=1 -v
✅ Expected Behavior

The test must fail whenever occurred_at carries only second precision, because a
post-delete mutation then compares occurred_at <= deleted_at against the tombstone and the
<= fence supersedes content that was journalled after the delete. Coverage of that fence
must not depend on how fast the machine is: the collision has to be constructed, not hoped
for.

❌ Actual Behavior

It passes. With the enqueue landing in a later second than deleted_at, no assertion
observes the boundary, so the merged test shape reports success on the broken stamping. The
raw timestamps recorded below show the regression plainly: occurred_at has no fractional
part at all.

Operating System

Windows

Release Version (Report Context)

main 82846a1; PR #1895 head a517487

Agent / Client

Other

📋 Relevant Logs
# state: dd7fb2bc store.go (occurred_at from the datetime('now') column default)
   # merged test shape + a 1.1s gap before the post-delete enqueue
   $ go test ./internal/store/ -run 'TestProbeSameSecondFalseGreen' -count=1 -v
   === RUN   TestProbeSameSecondFalseGreen
       zz_falsegreen_probe_test.go:94: PROBE RESULT: the merged test shape reports PASS
       zz_falsegreen_probe_test.go:100: PROBE TIMESTAMPS: occurred_at="2026-10-15 16:48:45"
 deleted_at="2026-10-15 16:48:43.977332100" shares_second=false strictly_after=true
   --- PASS: TestProbeSameSecondFalseGreen (1.59s)
   PASS
   ok     github.com/Gentleman-Programming/engram/v3/internal/store   3.979s

   # a deterministic construction (asserts occurred_at > deleted_at within the same
   # second) fails on that very same broken stamping, which is what the merged test
   # shape should have done
   $ go test ./internal/store/ -run
 'TestDeleteProjectTombstoneKeepsSameSecondPostDeleteMutationPending' -count=1 -v
   === RUN   TestDeleteProjectTombstoneKeepsSameSecondPostDeleteMutationPending
       project_delete_tombstone_test.go:413: post-delete mutation "s-tomb-post-1" was
 superseded in the ordinary pass ({Seq:3 Project:hotel Entity:session EntityKey:s-tomb-post-1
 Op:upsert ReasonCode:local_entity_deleted ...}); it must stay pending
   --- FAIL: TestDeleteProjectTombstoneKeepsSameSecondPostDeleteMutationPending (0.46s)
   FAIL
   FAIL   github.com/Gentleman-Programming/engram/v3/internal/store   2.913s
   FAIL
💡 Additional Context
  • Reported by the author of #1851, the hard-delete tombstone gap this fence guards.
    • Filed separately from #1851 because #1851 covers the missing project tombstone itself
      (fix in review at #1895); this is specifically the regression test's coverage of the fence.
    • Fix shape: derive the tombstone boundary from the mutation's own occurred_at, then
      assert occurred_at > deleted_at while sharing that second, and assert dispositions in both
      the ordinary and the folded pass. No clock seam is added and production behaviour is
      unchanged, so the diff stays test-only.
    • gofmt is not enforced by CI here (.golangci.yml enables only errcheck, staticcheck
      and unused), so this is about coverage, not formatting.
    • Related: #1851, PR #1895.
Dominant language
Go
Stars
7.1k
Forks
729
Avg merge
9h 12m
Merged PRs (30d)
331

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Gentleman-Programming/engram

All issues in Gentleman-Programming/engram

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.