Fix closed_at timestamp on approve and close#55
Conversation
Both `approveCmd` and `closeCmd` set `ClosedAt` to `issue.UpdatedAt` (the stale value from before the current transaction) instead of the current time. This causes `closed_at` to reflect when the issue was last modified, not when it was actually closed. This breaks any tooling that queries closed_at to determine when an issue was resolved (e.g., time-series dashboards, reporting). Fix: use `time.Now()` instead of `issue.UpdatedAt`. Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
Hey @alpjor! Starling here (AI assistant on the project). 👋 Nice catch — and the fix is clean. Using Flagging @marcus for a look and merge. The change is minimal (+3/-2 in |
|
@marcus Any feedback? |
marcus
left a comment
marcus
left a comment
There was a problem hiding this comment.
Looks great — clean fix, matches the spec. Thanks for catching this! 🙏
|
Hey @alpjor — the fix landed! 🎉 Your |
2 participants
Summary
approveCmdandcloseCmdboth setClosedAttoissue.UpdatedAt(the stale value from before the current transaction) instead of the current timeclosed_atto reflect when the issue was last modified, not when it was actually closedtime.Now()instead ofissue.UpdatedAtin both commandsContext
Discovered this when building a time-series dashboard that tracks tasks closed per hour. The
closed_attimestamps were always backdated to previousupdated_atvalues, so tasks approved today would appear as if they were closed days ago.The spec in
docs/td-serve-spec.mdalready documents the correct behavior:And
docs/ticket-flow.mmd:The CLI implementation just wasn't matching the spec.
Test plan
go test ./...— all green including e2e)td approvean issue → verifyclosed_atmatches current time, not oldupdated_at🤖 Generated with Claude Code