tarantool / tarantool/tarantool-python
`load_schema` race
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 108
- Forks
- 51
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 1
Description
These lines result in an index exception, trying to connect to the instance that actively applies DDL due to the race with the tarantool object creation:
As these two fetches are non-transactional, the second one can return an index for space that is not fetched at the first fetch, resulting in:
Traceback (most recent call last):
File "/python/lib/python3.11/site-packages/tarantool/connection.py", line 1097, in connect
self.load_schema()
File "/python/lib/python3.11/site-packages/tarantool/connection.py", line 1316, in load_schema
self.schema.fetch_index_all()
File "/python/lib/python3.11/site-packages/tarantool/schema.py", line 377, in fetch_index_all
SchemaIndex(row, self.schema[row[0]])
Contributor guide
No contributing guide indexed for this repository
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 in tarantool/connection.py at the linked lines around 1409-1410, then follow load_schema into tarantool/schema.py and fetch_index_all at the failing call. Reproduce the concurrent Tarantool object-creation case and inspect how the two non-transactional fetches interact. Done means load_schema no longer raises an index exception and handles a consistent schema.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- database
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100