dimensionalOS / dimensionalOS/dimos
Memory2 reads erroring out in concurrent access
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 4.5k
- Forks
- 808
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 233
Description
Description
System
macOS 14.5 (23F79), Apple Silicon (arm64). Python
3.12.13, sqlite3 3.50.4 (threadsafety=3).
Robot/Sim/Hardware (including firmware version)
N/A — pure library bug, reproduced offline from a recorded .db (no robot/sim needed).
Steps to reproduce
script: https://gist.github.com/Mgczacki/d0e01da287d7f53fec9bcf74318741e7
demo_sqlite_concurrency.py data/go2_short.db
DimOS version
origin/main (d2e695b38)
Logs / screenshots
baseline: color_image.count() == 855 (every read should return this)
unlocked (shared connection) -> {'ok': 19337, 'wrong(0)': 4092, 'error:TypeError': 571}
locked (one threading.Lock) -> {'ok': 24000} 4,092 / 24,000 reads returned 0 and 571 raised, for a query whose correct answer is 855.
Same profile on go2_hongkong_office.db (baseline 7953): 5,076 zeros + 577 errors. Serializing behind one threading.Lock makes all 24,000 correct.
Synced from DIM-952 by summer
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked demo_sqlite_concurrency.py reproduction and run it against data/go2_short.db, comparing the shared-connection and locked results. Trace the Memory2 read path involved in concurrent SQLite access; done means repeated reads return the expected color_image.count() without requiring one external threading.Lock.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, sqlite
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100