rclone bisync reads stale content from Tigris edge cache for non-US users

[phernandez]

Problem

Users outside the US (e.g., Europe) get stale file content when running bm project bisync because Tigris object storage uses eventual consistency globally by default. The tenant's data is stored in iad (US East), and reads from other regions hit edge-cached copies that may be outdated.

Symptoms

• rclone cat returns old content (e.g., 2048 bytes) while the actual S3 object is current (e.g., 8257 bytes)
• bm project bisync --resync reports "No changes found" even though files were updated via MCP or the web app
• Same credentials, same bucket, same path — different content depending on geographic location

Root Cause

Tigris provides strict read-after-write consistency within the same region but only eventual consistency globally. Reads from edge nodes outside the origin region (iad) can return stale cached content.

Tigris supports a X-Tigris-Consistent: true request header to force global strong consistency on a per-request basis: https://www.tigrisdata.com/docs/objects/consistency/

Fix

Add X-Tigris-Consistent: true header to rclone commands in rclone_commands.py. rclone's S3 backend supports custom headers via the --header-download and --header-upload flags:

--header-download "X-Tigris-Consistent: true"
--header-upload "X-Tigris-Consistent: true"

These should be added to project_bisync(), project_sync(), project_check(), and project_ls() in src/basic_memory/cli/commands/cloud/rclone_commands.py.

Also related

get_rclone_config_path() in rclone_config.py hardcodes ~/.config/rclone/ which doesn't match the actual rclone config location on Windows when installed via Scoop or Chocolatey. Should use rclone config file for runtime discovery. (See separate support case — two users hit this independently.)

Affected Users

• Any user outside the US syncing via rclone
• Confirmed with a user in Germany getting stale reads consistently

[claude]

Claude finished @phernandez's task in 3m 26s —— View job • claude/issue-548-20260207-1809 • Create PR ➔

---

Implementation Complete

Todo List

• Triage issue (classify and add labels)
• Read affected files to understand current implementation
• Add X-Tigris-Consistent: true headers to rclone commands
• Fix Windows config path issue in rclone_config.py
• Check and update related tests
• Commit and push changes
• Provide PR link

Changes Made

1. Added Tigris consistency headers to rclone commands (src/basic_memory/cli/commands/cloud/rclone_commands.py:208-217, 277-290, 352-361, 396-401):

• Modified project_sync(), project_bisync(), project_check(), and project_ls()
• Added --header-download "X-Tigris-Consistent: true" and --header-upload "X-Tigris-Consistent: true" flags
• This forces global strong consistency for non-US users hitting Tigris edge caches
• Resolves the issue where rclone reads stale cached content from edge nodes

2. Fixed Windows config path detection (src/basic_memory/cli/commands/cloud/rclone_config.py:24-48):

• Modified get_rclone_config_path() to use rclone config file for runtime detection
• Falls back to default ~/.config/rclone/rclone.conf if command fails
• Supports Scoop, Chocolatey, and manual installations on Windows
• Resolves the hardcoded path issue affecting Windows users

3. Updated tests:

• Added assertions in test_rclone_commands.py to verify consistency headers are present in all commands
• Added new tests in test_rclone_config_and_bmignore_filters.py:
  • test_get_rclone_config_path_uses_runtime_detection() - Verifies runtime detection works
  • test_get_rclone_config_path_falls_back_on_error() - Verifies fallback behavior

Notes

The implementation follows the exact solution proposed in the issue. The X-Tigris-Consistent: true header ensures that reads from any geographic location (including Europe) will return current data rather than stale edge cache copies. This is particularly important for bisync operations where consistency is critical.

The Windows config path fix ensures that the correct rclone configuration is used regardless of installation method, which was causing issues for users with non-standard installations.

---