release: v6.8.2

[code-crusher]

Summary

• Update check now invalidates stale cache when the running version is newer than the cached latest. Previously, a cached latest older than the running version (e.g. after npm install -g from another terminal) would hide a genuinely newer release until the 1-hour TTL expired. The cache is now treated as stale whenever cached.latest < current, forcing an immediate re-fetch.

Pre-release checklist

• npm run typecheck and npm run build pass locally
• version bumped in package.json (6.8.1 → 6.8.2) and not already on npm
• CHANGELOG.md updated with dated section

[matterai-app]

Summary By MatterAI <a href="https://app.matterai.so" target=""_blank">

🔄 What Changed

• Bumped package version to 6.8.2 in package.json.
• Added cache validity check in src/utils/updateCheck.ts to invalidate stale caches where cached version is older than the currently running version.

🔍 Impact of the Change

• Ensures users who update via alternate paths (e.g., global npm installs from external terminals) do not have newer updates hidden by stale local cache data.

📁 Total Files Changed

Click to Expand

File	ChangeLog
Version Bump package.json	Updated package version from previous release to 6.8.2.
Cache Validation src/utils/updateCheck.ts	Added conditional check to invalidate cached version if it is older than the current running version.

🧪 Test Added/Recommended

Recommended

• Add unit tests verifying isCacheValid correctly invalidates caches when the running version exceeds the cached version.

🔒 Security Vulnerabilities

• None detected.

[matterai-app]

🧪 PR Review is completed: Release bump to v6.8.2 plus a smart fix that invalidates a stale cached latest older than the running version. The fix works for the updated-user case, but permanently bypasses the cache for anyone running a version newer than npm latest (dev/pre-release builds), causing a registry hit on every launch.

Skipped files

• CHANGELOG.md: Skipped file pattern
• package-lock.json: Skipped file pattern

⬇️ Low Priority Suggestions (1)

src/utils/updateCheck.ts (1 suggestion)

Location: src/utils/updateCheck.ts (Lines 122-130)

🔵 Performance / Cache Design

Issue: The new staleness check (cached.latest === null || compareVersions(cached.latest, current) >= 0) permanently opts out of caching for any user whose running version is newer than the npm latest — e.g. dev checkouts, pre-release builds, or maintainers testing the next version before publish. For those users cached.latest < current on every launch, so cacheValid is always false and the 1-hour TTL rate-limit is defeated: getUpdateInfo hits the npm registry on every single launch, forever. The old code guaranteed at most one registry hit per TTL window.

Fix: Persist the running version at check time (e.g. a currentAtCheck field in CachedCheck). Treat the cache as valid when cached.currentAtCheck === current — a refetch then happens only when the running version actually changes (the exact scenario the comment describes: user updated via a path that didn't clear the cache), while dev builds go back to being rate-limited by the TTL.

Impact: Restores the registry rate-limiting for dev/pre-release installs while preserving the stale-cache fix for updated users.

-    const cacheValid =
-      cached &&
-      Date.now() - cached.checkedAt < CACHE_TTL_MS &&
-      // A cached `latest` older than the running version is stale by
-      // definition — the user updated through some path that didn't clear
-      // the cache (e.g. `npm install -g` from another terminal). Trusting it
-      // would hide the *real* newer version on npm.
-      (cached.latest === null || compareVersions(cached.latest, current) >= 0);
-    if (cacheValid) {
+    const cacheValid =
+      cached &&
+      Date.now() - cached.checkedAt < CACHE_TTL_MS &&
+      // A cached `latest` older than the running version is stale by
+      // definition — the user updated through some path that didn't clear
+      // the cache (e.g. `npm install -g` from another terminal). Trusting it
+      // would hide the *real* newer version on npm. But if we already
+      // re-checked while running this exact version (dev/pre-release builds
+      // run newer than npm `latest`), the cache is trustworthy until the
+      // running version changes again.
+      (cached.latest === null ||
+        compareVersions(cached.latest, current) >= 0 ||
+        cached.currentAtCheck === current);