Skip to content

Conversation

EmanElsaban
Copy link
Contributor

@EmanElsaban EmanElsaban commented Aug 28, 2025

This PR upgrades Tron to Python 3.10. Tests are passing locally.

@EmanElsaban EmanElsaban requested a review from a team as a code owner August 28, 2025 16:37
@EmanElsaban EmanElsaban force-pushed the u/emanelsabban/TRON-2435 branch from 7de4c89 to 25be067 Compare August 28, 2025 16:39
"cleanup_run": None,
"manual": False,
"large_data": [i for i in range(1_000_000)],
"large_data": [i for i in range(10000)],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was this meant to be changed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea, I was getting this error
ClientError('An error occurred (ValidationException) when calling the TransactWriteItems operation: Item size has exceeded the maximum allowed size')
moto's mock enforces a 400kb item size limit and the 1000000 serializes to a json object greater than 400kb. I think older versions of moto didn't enforce this size limit and now that we upgraded moto it enforces it. So I reduced the number of integers we create here to be below that limit

Copy link
Member

@nemacysts nemacysts Aug 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gotcha! i assume that since the tests are still passing, then we're still ending up splitting this object

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect that by reducing the data to 10,000 integers, we're now creating an object that is smaller than our OBJECT_SIZE of 200KB. This would mean it no longer gets partitioned, and these tests are no longer verifying the multi-partition logic they were designed for.

Maybe we should also add an assert num_partitions(key) > 1 in these tests to guarantee we're actually testing the partitioning logic?

Also, outside the bounds of this PR, it might be a good time to rename these tests to something like test_save_object_requiring_partitioning. more_than_4KB is technically correct but confusing 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

iirc from some manual tests, 50,000 gets us ~2 partitions

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think what might be happening here is related to OBJECT_SIZE. We don't leave a lot of overhead with our current limit. You could try changing OBJECT_SIZE to 150,000. Keep in mind that we still want to make sure we're setting large object in a way that both the pickle and json are getting partitioned.

return source.split(",")

def parse(self, source: str) -> Optional[Union[List[int], List[Union[int, str]]]]:
def parse(self, source: str) -> list[int] | list[int | str] | None:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i have no idea why i initially wrote this type this way rather than list[int | str] | None

we can fix this in another PR though and leave this one a pretty mechanical transformation to this form of typing tho

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay will leave it as it is now then

@EmanElsaban EmanElsaban requested a review from nemacysts August 29, 2025 13:25
Copy link
Member

@KaspariK KaspariK left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm aside from the partitioning stuff I mentioned

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants