Tempest coerces the type of records when querying a GSI
- Dominant language
- Kotlin
- Stars
- 90
- Forks
- 42
- Avg merge
- 46m
- Merged PRs (30d)
- 1
Description
Tempest assumes the type of records when querying a GSI, and coerces all records to be that type without checking the entity sort key prefix.
---
### Example
Let's say we have a library hold system that tracks holds on Books and Movies. We might have:
- Book Hold
- Hold Token (PK): String
- Book Token: String
- Hold placed at: Instant
- Title, author, other metadata
- Movie Hold
- Hold Token (PK): String
- Movie Token: String
- Hold placed at: Instant
- Director, actors, other metadata
When a loaned book/movie gets returned, the library would need to give it to the next person in line. To faciliate that, we'd need a GSI. We could build one for books and one for movies, but the idiomatic dynamo approach would be to share a GSI, and have the following schema:
- Book/movie token (PK)
- Hold placed at (SK)
That way the system can easily allocate the pending holds by looking at the oldest hold for a given book.
---
### The Problem
Tempest has no type safety here. If you look up `book_token_123` in the tempest movie GSI, it'll try to return a book (ignoring the sort key prefix), and can very well succeed if you have enough nullable fields.
This surfaced for me as a bug - I bumped the schema version on my table (including giving it a new sort key prefix), and then my code proceeded to pull the old records out of the table, coerced as new records, and caused lots of mayhem.
---
### Solutions
This feels like it's safely in bug territory but I wanted to consult with you folks on solutions before putting up a fix. In my mind tempest just needs to be checking that the correct prefix exists before using the Codec to parse it.
Contributor guide
Research direction
Start by tracing the GSI query path in Tempest and identify where the entity sort key prefix is available before Codec parsing. Compare the queried prefix with the expected record type, then verify that records with mismatched prefixes are not coerced into that type and that the existing query behavior remains intact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, kotlin
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100