chore: adopt Go 1.27

[mariusvniekerk]

Move msgvault's supported build toolchain to Go 1.27.0 across the module, CI and release-derived setup, container builders, Nix packaging, and source-build documentation.

Pin golangci-lint 2.13.1, set its analyzer language level to Go 1.27, and adopt its gomodguard_v2 replacement. Apply the Go 1.27 modernization rewrites required by that pinned analyzer, including typed errors.As calls and promoted embedded fields. CI installs the linter through the versioned Make target and prepends its bin directory so self-hosted runners cannot select an older cached binary.

The Nix development shell now builds gopls 0.23.0, gotools 0.44.0, golangci-lint 2.13.1, and Delve 1.27.1 with the same pinned Go 1.27.0 compiler. Delve retains its test phase but skips two generator checks whose versioned tool queries conflict with Go 1.27's forced vendoring behavior.

Update go-sqlite3 to v1.14.50, its current stable release, so the migration uses the maintained SQLite amalgamation and recent driver fixes. The driver update alone did not remove the Go 1.27 database/sql close-mutex deadlock: msgvault's logging wrapper consumed Rows.Err at the end of Next, then normal callers consumed it again. Capture the terminal row error once and return that cached result, preserving SQL logging without the second lock acquisition.

Historical implementation plans remain unchanged because their older Go versions describe work at the time rather than active build support.

^{generated by a clanker}

[roborev-ci]

roborev: Combined Review (c3bb337)

The Go 1.27 upgrade is generally sound, but the Nix development shell retains incompatible tooling.

Medium

• flake.nix:101 — The shell uses Go 1.27 while gopls, golangci-lint, and Delve come from the older locked nixpkgs revision. Notably, it misses CI’s golangci-lint v2.13.1 upgrade, which can break linting and editor workflows for Nix users. Pin Go 1.27-compatible tool versions built with goPinned, especially golangci-lint v2.13.1, or update flake.lock to a compatible nixpkgs revision.

---

Reviewers: 2 done | Synthesis: codex, 8s | Total: 6m14s

[roborev-ci]

roborev: Combined Review (0896537)

No issues found.

---

Reviewers: 2 done | Synthesis: codex | Total: 6m48s

[wesm]

looking

[roborev-ci]

roborev: Combined Review (a7638ff)

Verdict: Two medium-severity Nix dependency hash issues must be fixed.

Medium

• go.mod:33, nix/package.nix:19 — Updating go-sqlite3 changes the dependency closure, but the Nix vendorHash remains unchanged, preventing the package from realizing its vendored modules. Regenerate and update nix/package.nix’s vendorHash.

• flake.nix:75 — delvePinned replaces Delve’s version and source while retaining the locked package’s vendor hash for the previous dependency graph, preventing the development shell from realizing Delve. Add the regenerated vendorHash for Delve v1.27.1.

---

Reviewers: 2 done | Synthesis: codex, 8s | Total: 5m25s

[roborev-ci]

roborev: Combined Review (75237f5)

No issues found.

---

Reviewers: 2 done | Synthesis: codex | Total: 7m26s

[roborev-ci]

roborev: Combined Review (095dfaa)

No issues found.

---

Reviewers: 2 done | Synthesis: codex | Total: 6m32s

[wesm]

i'm back looking at this

[roborev-ci]

roborev: Combined Review (5960fe3)

Concurrency handling remains incomplete on SQLite, with two medium-severity transaction races.

Medium

• internal/store/document_index.go:1195 — Concurrent reconciliations can read the same snapshot. After one commits, the other may fail with SQLITE_BUSY_SNAPSHOT instead of converging because serialization currently covers only PostgreSQL. Retry the whole transaction with retryContendedWriteErr, or acquire SQLite’s writer lock before the initial reads. Add a deterministic test for this read/write interleaving.

• internal/store/attachment_changes.go:227 — The cursor recheck does not eliminate the analogous SQLite race: a transaction retaining the old snapshot can still see the pruned event, then fail when upgrading its stale snapshot during the conditional update. Reserve the SQLite writer before reading, or retry busy/conflict failures around the entire transaction.

---

Reviewers: 2 done | Synthesis: codex, 7s | Total: 10m24s

[wesm]

still grinding on this

[roborev-ci]

roborev: Combined Review (9421abc)

The change has one medium-severity concurrency flaw; no critical or high-severity issues were found.

Medium

• Stale attachment occurrence can be reinserted during concurrent reconciliation — internal/store/document_index.go:305,1194

  Reconciliation reads attachment metadata before acquiring the serialization lock, while removals do not share the PostgreSQL advisory lock. A lower-sequence reconciliation can read eligible metadata and pause; a higher-sequence reconciliation can then remove and acknowledge the occurrence; finally, the lower-sequence operation can resume and reinsert stale data because no row remains to enforce the sequence guard.

  Fix: Acquire the backend-specific lock before reading metadata, and perform eligibility evaluation plus upsert/removal within the same transaction using the shared lock. Add a regression test for a concurrent eligible-to-ineligible transition.

---

Reviewers: 2 done | Synthesis: codex, 8s | Total: 8m19s