Skip to content

Conversation

@CaymanWilliams
Copy link
Contributor

@CaymanWilliams CaymanWilliams commented Dec 11, 2023

Passes all current tests, tested a few of the methods that changed individually (locally) but haven't done an exhaustive test of each method. It seems like everything should be working. The package differences are the options for encoding datetimes and the fact that json.dumps is a str and orjson.dumps is bytes. The echo calls in the cli don't care if the output is bytes or strings, and all other dumps calls have been cast to bytes. The utils folder has a custom class that encodes datetimes the same as orjson.

Comment on lines 372 to 379
bytes(
json.dumps(
{
"instances": list(all_vms_by_id.values()),
"timelines": all_timelines,
}
),
"utf-8",
Copy link
Contributor

Choose a reason for hiding this comment

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

I recall you saying that json dumps to a str while orjson dumps to bytes. Does the bytes format need to be adhered to here because the s3 write requires bytes? Just curious if/how this fails if you don't format it as bytes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, if it's not cast into bytes you get a boto3 error that says something along the lines of file obj needs to be in bytes for s3. I don't recall the exact verbiage, but it was definitely a fatal error

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well actually, that's true for this line

s3.upload_fileobj(
. The write_file function you're talking about here expects bytes and manipulates the body expecting it to be bytes. It throws an error: TypeError: a bytes-like object is required, not 'str'. It looks like dbfs expects file content to be in b64.

Copy link
Contributor

@gorskysd gorskysd left a comment

Choose a reason for hiding this comment

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

Looks like there are a few more orjson usages you missed.
image

Also, don't forget to bump the version!

@CaymanWilliams
Copy link
Contributor Author

CaymanWilliams commented Dec 12, 2023

Looks like there are a few more orjson usages you missed. image

Also, don't forget to bump the version!

Oh man, looks like some files weren't saved but the changes were made locally so search isn't useful. Delightful. I'll go through and close all the tabs in my vscode and make sure they're saved. The good news is I was testing with these changes actually made

gorskysd
gorskysd previously approved these changes Dec 13, 2023
Copy link
Contributor

@gorskysd gorskysd left a comment

Choose a reason for hiding this comment

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

Nice, everything looks good to me!

@CaymanWilliams
Copy link
Contributor Author

This last change fixes a bug where the _monitor_cluster methods were unable to write out the instance data because it needed it's own datetime encoder class in the json utils file. I've done some janky tests where I run diff on the new _monitor_cluster output and everything looks identical. The cli is unaffected, I've tested the clients and the encode_json method is working correctly for both clients.

Copy link
Contributor

@gorskysd gorskysd left a comment

Choose a reason for hiding this comment

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

Ran a successful test on both AWS and Azure. Looks good to me!

@CaymanWilliams CaymanWilliams merged commit 73aaf53 into main Dec 18, 2023
@CaymanWilliams CaymanWilliams deleted the PROD-1440-replace-orjson-with-json branch December 18, 2023 17:56
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