Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

`LocalFileIdentifiableStore`: add per-object write locking to prevent silent data loss under concurrent writes

Open
#554 0 comments 0 reactions 0 assignees View on GitHub

@hpoeche is already working on this.

Since Jul 14, 2026.

  • #591 by @hpoeche — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
30/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Stale
Tech stack
python
Domain
backend, distributed-systems

Research direction

Start at LocalFileIdentifiableStore._write_atomic() and review how concurrent workers currently create temporary files and call os.replace(). Check the linked pull request for the work already in progress. Done means concurrent writes to the same object no longer silently lose data, locks are released on exceptions, and the relevant concurrency behavior is covered by tests if the pull request adds them.

Written by the indexing model from the issue text.

Description

enhancement sdk

LocalFileIdentifiableStore has no concurrency control across processes. Under a multi-worker WSGI deployment, two workers handling concurrent requests that modify the same object will each call commit(), write to separate temp files, and then race on os.replace(). The last writer wins silently (no exception, no conflict signal, no log entry). The earlier write is permanently lost.

CouchDB avoids this via _rev/409: the caller is forced to detect and resolve the conflict. The local file path has no equivalent mechanism.

I suggest to take an advisory lock on a stable sibling lockfile (<hash>.lock) for the duration of the write in _write_atomic(). A sibling lockfile is preferred over locking the JSON file itself because os.replace() swaps the inode, so a lock held on the old file does not carry over to the replacement.

fcntl.flock is sufficient for single-host deployments (the local file backend implies a single host by design) and is safe under uWSGI multi-worker mode. It should be wrapped in a try/finally to guarantee the lock is released even on exception or KeyboardInterrupt.

This issue has been found by @zrgt during review of #553.

Dominant language
Python
Stars
102
Forks
52
Avg merge
20d 17h
Merged PRs (30d)
1

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from eclipse-basyx/basyx-python-sdk

All issues in eclipse-basyx/basyx-python-sdk

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.